User: Password:
|
|
Subscribe / Log in / New account

GNU + Linux = broken development model

GNU + Linux = broken development model

Posted Jul 29, 2009 18:23 UTC (Wed) by me@jasonclinton.com (✭ supporter ✭, #52701)
In reply to: GNU + Linux = broken development model by mheily
Parent article: A tempest in a tty pot

You ignored the part of my response where I pointed out that there are thousands of TTY consumer in *BSD. At this point, I'm just going to assume that you're trolling and not respond to this thread any further.


(Log in to post comments)

GNU + Linux = broken development model

Posted Jul 29, 2009 18:55 UTC (Wed) by mheily (guest, #27123) [Link]

Fine. Please ignore the rest of this comment because anything you don't agree with must be a troll. Continuing with the hypothetical example of TTY changes to a BSD-based operating system...

In order to coordinate changes to the kernel TTY code that potentially impact thousands of userland programs, you would need a team of developers and testers to go through the code looking for problems. First, you fix problems in the the core userland programs (aka. the "base system"). The source code for everything is under /usr/src, so you can start with:

$ find /usr/src -type f -exec grep '#include <pty.h>' {} \;

After you have a patch for the base system, you install the entire ports tree and repeat the search. Ports are installed under /usr/ports, so the command is:

$ find /usr/ports -type f -exec grep '#include <pty.h>' {} \;

Once you have a list of potential problematic ports, you send out a notice to the ports maintainers and users of the -CURRENT branch asking them to test the affected ports against the experimental TTY patch for the base system. Some ports, such as Emacs, may rely on the old behavior, so they will need to be patched. These ports will require patches in order to make them work with the new kernel. Other ports may not need any changes at all.

Once all the changes are tested and reviewed (kernel, base system, and ports), the combined patchset is applied to the -STABLE branch for inclusion in the next stable release. All of this development and testing is costly, so hopefully the kernel changes were worth it :)

GNU + Linux = broken development model

Posted Jul 29, 2009 19:12 UTC (Wed) by bronson (subscriber, #4806) [Link]

KDE and Emacs, the two things that broke in the article, aren't a part of BSD. It's true that fixing code in ports is easy, just like patching a .deb or .rpm is easy.

That's not where the problem lies. Here's are the hard parts:

- testing the app, figuring out if there are bugs
- finding the bugs, fixing the bugs
- getting code review, regressing your fixes
- upstreaming your patches. All they do is work around a new and obscure kernel bug? Good luck with that!

And THAT is why the kernel <-> user space API should be stable. I like ports as much as anybody else but they just don't help much here.

GNU + Linux = broken development model

Posted Jul 29, 2009 20:02 UTC (Wed) by nix (subscriber, #2304) [Link]

And if TTY code was that easy to grep for, maybe it would be simple: we
have distributors who can point to such code.

But it is not. TTY users can be people who accept file descriptors via
pipes and have no idea there are TTYs at the other end: they can be people
who use the Unix98 or the old BSD pty interface (which still has users!);
every use of ioctl() has to be audited: the signal handling in TTY users
has to be checked; it ties in with process groups...

The TTY stuff introduced in the early BSD Unix is, let's be blunt, a
bloody design mess, and a pervasive one. It's not a nice simple <pty.h>
interface, by any means, although it should have been.

Passing fds via pipes?!

Posted Jul 30, 2009 0:01 UTC (Thu) by i3839 (guest, #31386) [Link]

> TTY users can be people who accept file descriptors via
> pipes and have no idea there are TTYs at the other end

How is this possible? Did you mean unix domain sockets instead of pipes?

Passing fds via pipes?!

Posted Jul 30, 2009 0:37 UTC (Thu) by nix (subscriber, #2304) [Link]

Wrong way round. An fd to a TTY can be passed over a unix-domain socket
and then used (which will trigger line discipline magic even though the
app has no idea it's using it), so it's using a TTY even though it never
opened it or looked at /dev/ptmx. (This is probably not common, but it
makes a comprehensive audit of TTY users ridiculously hard, because use of
AF_UNIX sockets *is* common and fd passing is not particularly rare. One
variation of it, in which the fd is passed into the application as one of
fds 0 to 2, is of course exceedingly common. You don't even need AF_UNIX
sockets for that.)

GNU + Linux = broken development model

Posted Jul 29, 2009 22:46 UTC (Wed) by jond (subscriber, #37669) [Link]

...and then your user's custom code, not part of the OS, breaks when you release.

GNU + Linux = broken development model

Posted Jul 30, 2009 4:47 UTC (Thu) by daniels (subscriber, #16193) [Link]

On GNU userspace, you could use grep -r. ;)

(This is a blatant, content-free, troll.)

GNU + Linux = broken development model

Posted Aug 7, 2009 11:01 UTC (Fri) by efexis (guest, #26355) [Link]

"(This is a blatant, content-free, troll.)"

You kiddin? That's the most helpful thing I've read this thread! :-)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds