--On January 20, 2006 5:34:33 PM +0100 Marc Koschewski
<[email protected]> wrote:
I know. But you we're the one who started this off. The 'beast' should be
maintained by people that need it. And it was just a brainstorm, moreover.
Understood. However these sorts of changes are still more appropriate in a
development kernel/tree, not in what's generally supposed to be accepted as
a stable code base.
Lots of things still out there depend on devfs. So now if I want to
develop my kmod on recent kernels I have to be in the business of
maintaining a lot more userland stuff, like mkinitrd, installers, etc.
that have come to rely on devfs.
What exactly relies on _devfs_?
devfs=mount/nomount for one in kernel params, mount commands for another
(mount -t devfs ....), modprobe devfs, these are at the lowest level.
Scripts are written, as are bits of code, with the assumption that they'll
get their /dev tree/dependency satisfied in a certain way.
The point is this is happening in what is being called a stable kernel.
Stable it isn't. The whole devfs thing is likely to cause me a lot of
work, I'd stay with 2.4 in the worst affected things, but I can't.
devfs is newish for and already been deprecated and killed before a
major release even, that just seems not right.
As far as I remember the devfs maintainer didn't do just a one-liner of
changes plus he was not to be reached by mail. No reply, no list
acitivity, ... nothing. Just out of the town.
Anyway hopefully this thread wills tart some constructive thought on
this rather than being pointless, but I had to get it out there. I
know I have a habit of showing up every other year or so. :)
This thread will start something, yes. But I don't think we will have a
decision in the end. The kernel grows. In size, in features, in just
about anything. And from a developers point of view it's always wise to
re-write a subsystem with a new API and the freedom to do _whatever_ one
thinks she could do than re-write a subsystem due to maintaining the
interface for compatibility.
Which is fine in a development tree. The problem here is making these
changes, blowing away APIs, especially userland ones, in a stable tree.
For various reasons embedded systems will often need to stay current with
the 'stable' kernel. You try developing modules against a 'stable' kernel
for embedded purposes when things are changing under you. Yes that's a
partially commercial argument, but it's also a general argument. The even
numbered releases are/were supposed to be atleast mostly stable. And in my
mind atleast that means that APIs don't come and go on a whim.
The two cases exactly are:
* _new_ code with all new features planned
or
* _partly new_ code with some new features due to API incompatibility a
la 'what we have to do is to get the best we can from what we have'
And the latter is definitely the wrong way to go. Just my 2 cents...
Which is why everyone else seperates development from maintenance. AIX,
HP-UX, even Windows does (ok...so maybe not Windows).
The problem is these sorts of changes are 'normally' reserved for
development trees because they can break (and will) break things and they
obviously change things.
What do you think would happen if OpenSSL changed it's API incompatibly in
say (arbitrarily) six months for a point release doing away with something
in a stable release?
I guess I'm just the net.kook and the only one spending time and effort to
clean up a mess created simply because he needed to go up a point rev, and
atleast one otherwise working feature.
No devfs was not, is not perfect, and I agree something better was needed,
but in a stable kernel? I'm arguing against userland API changes
specifically in stable kernels, and in a more broad sense even internal API
changes in a stable kernel, atleast where they most certainly affect
development of code, or maintenance releases of code requiring upgrades of
the kernel in general.
If 2.6 were stable I should be able to write a module for the '2.6' API,
like PHP, like Apache, like Zend, like OpenSSL, and be reasonably certain
that atleast the API wasn't going to drastically change or go away when I
rebuild the binaries for a security update or 'minor' update of say needing
support for the new PCI IDs of the latest e1000 variants.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
