[GIT PATCH] Remove devfs from 2.6.13

[GIT PATCH] Remove devfs from 2.6.13

[Greg KH]

Here are the same "delete devfs" patches that I submitted for 2.6.12.
It rips out all of devfs from the kernel and ends up saving a lot of
space.  Since 2.6.13 came out, I have seen no complaints about the fact
that devfs was not able to be enabled anymore, and in fact, a lot of
different subsystems have already been deleting devfs support for a
while now, with apparently no complaints (due to the lack of users.)

I mean, how can you go wrong with deleting over 8000 lines of kernel
code :)

So, please pull from:

Please pull from:
	rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/
or if master.kernel.org hasn't synced up yet:
	master.kernel.org:/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/

I've posted all of these patches before, but if people really want to look at them, they can be found at:
	http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/

Also, if people _really_ are in love with the idea of an in-kernel
devfs, I have posted a patch that does this in about 300 lines of code,
called ndevfs.  It is available in the archives if anyone wants to use
that instead (it is quite easy to maintain that patch outside of the
kernel tree, due to it only needing 3 hooks into the main kernel tree.)

thanks,

greg k-h

 Documentation/filesystems/devfs/ChangeLog         | 1977 ---------------
 Documentation/filesystems/devfs/README            | 1964 ---------------
 Documentation/filesystems/devfs/ToDo              |   40 
 Documentation/filesystems/devfs/boot-options      |   65 
 arch/i386/kernel/microcode.c                      |    1 
 arch/ppc/4xx_io/serial_sicc.c                     |    2 
 arch/sh/kernel/cpu/sh4/sq.c                       |    1 
 arch/sparc64/solaris/socksys.c                    |    4 
 arch/um/drivers/line.c                            |    2 
 arch/um/drivers/ssl.c                             |    1 
 arch/um/drivers/stdio_console.c                   |    1 
 arch/um/drivers/ubd_kern.c                        |   18 
 arch/um/include/line.h                            |    1 
 drivers/block/DAC960.c                            |    1 
 drivers/block/acsi.c                              |    5 
 drivers/block/acsi_slm.c                          |   10 
 drivers/block/cciss.c                             |    1 
 drivers/block/cpqarray.c                          |    5 
 drivers/block/floppy.c                            |   55 
 drivers/block/loop.c                              |    6 
 drivers/block/nbd.c                               |    5 
 drivers/block/paride/pg.c                         |   18 
 drivers/block/paride/pt.c                         |   21 
 drivers/block/pktcdvd.c                           |    1 
 drivers/block/ps2esdi.c                           |    1 
 drivers/block/rd.c                                |    5 
 drivers/block/swim3.c                             |    4 
 drivers/block/sx8.c                               |    5 
 drivers/block/ub.c                                |    6 
 drivers/block/umem.c                              |    1 
 drivers/block/viodasd.c                           |    3 
 drivers/block/xd.c                                |    1 
 drivers/block/z2ram.c                             |    1 
 drivers/cdrom/aztcd.c                             |    1 
 drivers/cdrom/cdu31a.c                            |    1 
 drivers/cdrom/cm206.c                             |    1 
 drivers/cdrom/gscd.c                              |    1 
 drivers/cdrom/mcdx.c                              |    1 
 drivers/cdrom/optcd.c                             |    1 
 drivers/cdrom/sbpcd.c                             |    6 
 drivers/cdrom/sjcd.c                              |    1 
 drivers/cdrom/sonycd535.c                         |    1 
 drivers/cdrom/viocd.c                             |    3 
 drivers/char/cyclades.c                           |    1 
 drivers/char/dsp56k.c                             |   10 
 drivers/char/dtlk.c                               |    5 
 drivers/char/epca.c                               |    1 
 drivers/char/esp.c                                |    1 
 drivers/char/ftape/zftape/zftape-init.c           |   25 
 drivers/char/hvc_console.c                        |    1 
 drivers/char/hvcs.c                               |    1 
 drivers/char/hvsi.c                               |    1 
 drivers/char/ip2main.c                            |   24 
 drivers/char/ipmi/ipmi_devintf.c                  |    8 
 drivers/char/isicom.c                             |    1 
 drivers/char/istallion.c                          |   13 
 drivers/char/lp.c                                 |    7 
 drivers/char/mem.c                                |    8 
 drivers/char/misc.c                               |   15 
 drivers/char/mmtimer.c                            |    2 
 drivers/char/moxa.c                               |    1 
 drivers/char/ppdev.c                              |   15 
 drivers/char/pty.c                                |    8 
 drivers/char/raw.c                                |   15 
 drivers/char/riscom8.c                            |    1 
 drivers/char/rocket.c                             |    5 
 drivers/char/serial167.c                          |    1 
 drivers/char/stallion.c                           |   14 
 drivers/char/tipar.c                              |   16 
 drivers/char/tty_io.c                             |   17 
 drivers/char/vc_screen.c                          |   11 
 drivers/char/viocons.c                            |    1 
 drivers/char/viotape.c                            |   10 
 drivers/char/vme_scc.c                            |    1 
 drivers/char/vt.c                                 |    2 
 drivers/i2c/i2c-dev.c                             |    7 
 drivers/ide/ide-cd.c                              |    2 
 drivers/ide/ide-disk.c                            |    2 
 drivers/ide/ide-floppy.c                          |    1 
 drivers/ide/ide-probe.c                           |   13 
 drivers/ide/ide-tape.c                            |   14 
 drivers/ide/ide.c                                 |   12 
 drivers/ieee1394/amdtp.c                          |   12 
 drivers/ieee1394/dv1394.c                         |   23 
 drivers/ieee1394/ieee1394_core.c                  |   16 
 drivers/ieee1394/ieee1394_core.h                  |    1 
 drivers/ieee1394/raw1394.c                        |    7 
 drivers/ieee1394/video1394.c                      |   14 
 drivers/input/evdev.c                             |    4 
 drivers/input/input.c                             |    7 
 drivers/input/joydev.c                            |    4 
 drivers/input/mousedev.c                          |    7 
 drivers/input/serio/serio_raw.c                   |    1 
 drivers/input/tsdev.c                             |    7 
 drivers/isdn/capi/capi.c                          |    5 
 drivers/isdn/hardware/eicon/divamnt.c             |    3 
 drivers/isdn/hardware/eicon/divasi.c              |    3 
 drivers/isdn/hardware/eicon/divasmain.c           |    3 
 drivers/isdn/i4l/isdn_tty.c                       |    3 
 drivers/macintosh/adb.c                           |    3 
 drivers/md/dm-ioctl.c                             |   30 
 drivers/md/dm.c                                   |    2 
 drivers/md/md.c                                   |   30 
 drivers/media/dvb/dvb-core/dvbdev.c               |   13 
 drivers/media/dvb/dvb-core/dvbdev.h               |    1 
 drivers/media/dvb/ttpci/av7110.h                  |    4 
 drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c |   11 
 drivers/media/radio/miropcm20-rds.c               |    1 
 drivers/media/video/arv.c                         |    1 
 drivers/media/video/videodev.c                    |   11 
 drivers/message/i2o/i2o_block.c                   |    1 
 drivers/mmc/mmc_block.c                           |    4 
 drivers/mtd/mtd_blkdevs.c                         |    6 
 drivers/net/ppp_generic.c                         |    9 
 drivers/net/tun.c                                 |    1 
 drivers/net/wan/cosa.c                            |   14 
 drivers/s390/block/dasd.c                         |    4 
 drivers/s390/block/dasd_genhd.c                   |    2 
 drivers/s390/block/dasd_int.h                     |    1 
 drivers/s390/block/xpram.c                        |    6 
 drivers/s390/char/monreader.c                     |    1 
 drivers/s390/char/tty3270.c                       |    3 
 drivers/s390/crypto/z90main.c                     |    1 
 drivers/s390/net/ctctty.c                         |    2 
 drivers/sbus/char/bpp.c                           |    9 
 drivers/sbus/char/vfc.h                           |    2 
 drivers/sbus/char/vfc_dev.c                       |    7 
 drivers/scsi/osst.c                               |   26 
 drivers/scsi/scsi.c                               |    3 
 drivers/scsi/scsi_scan.c                          |    6 
 drivers/scsi/sd.c                                 |    2 
 drivers/scsi/sg.c                                 |    9 
 drivers/scsi/sr.c                                 |    2 
 drivers/scsi/st.c                                 |   21 
 drivers/serial/21285.c                            |    1 
 drivers/serial/8250.c                             |    1 
 drivers/serial/au1x00_uart.c                      |    1 
 drivers/serial/crisv10.c                          |    2 
 drivers/serial/dz.c                               |    4 
 drivers/serial/imx.c                              |    1 
 drivers/serial/ip22zilog.c                        |    1 
 drivers/serial/m32r_sio.c                         |    1 
 drivers/serial/mcfserial.c                        |    1 
 drivers/serial/mpc52xx_uart.c                     |    1 
 drivers/serial/mpsc.c                             |    2 
 drivers/serial/pmac_zilog.c                       |    1 
 drivers/serial/pxa.c                              |    1 
 drivers/serial/s3c2410.c                          |    2 
 drivers/serial/sa1100.c                           |    1 
 drivers/serial/serial_core.c                      |    5 
 drivers/serial/serial_txx9.c                      |    3 
 drivers/serial/sh-sci.c                           |    3 
 drivers/serial/sunsab.c                           |    1 
 drivers/serial/sunsu.c                            |    1 
 drivers/serial/sunzilog.c                         |    1 
 drivers/serial/v850e_uart.c                       |    1 
 drivers/serial/vr41xx_siu.c                       |    1 
 drivers/tc/zs.c                                   |    3 
 drivers/telephony/phonedev.c                      |    4 
 drivers/usb/class/bluetty.c                       |    7 
 drivers/usb/class/cdc-acm.c                       |    3 
 drivers/usb/class/usblp.c                         |    3 
 drivers/usb/core/file.c                           |   19 
 drivers/usb/gadget/serial.c                       |    3 
 drivers/usb/image/mdc800.c                        |    3 
 drivers/usb/input/aiptek.c                        |    2 
 drivers/usb/input/hiddev.c                        |    6 
 drivers/usb/media/dabusb.c                        |    3 
 drivers/usb/misc/auerswald.c                      |    3 
 drivers/usb/misc/idmouse.c                        |    5 
 drivers/usb/misc/legousbtower.c                   |    5 
 drivers/usb/misc/rio500.c                         |    3 
 drivers/usb/misc/sisusbvga/sisusb.c               |    3 
 drivers/usb/misc/usblcd.c                         |    9 
 drivers/usb/serial/usb-serial.c                   |    3 
 drivers/usb/usb-skeleton.c                        |    7 
 drivers/video/fbmem.c                             |    5 
 fs/Makefile                                       |    1 
 fs/block_dev.c                                    |    1 
 fs/char_dev.c                                     |    1 
 fs/coda/psdev.c                                   |   23 
 fs/compat_ioctl.c                                 |    1 
 fs/devfs/Makefile                                 |    8 
 fs/devfs/base.c                                   | 2838 ----------------------
 fs/devfs/util.c                                   |   97 
 fs/partitions/Makefile                            |    1 
 fs/partitions/check.c                             |   32 
 fs/partitions/devfs.c                             |  130 -
 fs/partitions/devfs.h                             |   10 
 include/asm-ppc/ocp.h                             |    1 
 include/linux/compat_ioctl.h                      |    5 
 include/linux/devfs_fs.h                          |   41 
 include/linux/devfs_fs_kernel.h                   |   58 
 include/linux/fb.h                                |    1 
 include/linux/genhd.h                             |    2 
 include/linux/ide.h                               |    1 
 include/linux/miscdevice.h                        |    1 
 include/linux/serial_core.h                       |    1 
 include/linux/tty_driver.h                        |   14 
 include/linux/usb.h                               |    7 
 include/linux/videodev.h                          |    1 
 include/scsi/scsi_device.h                        |    1 
 init/Makefile                                     |    1 
 init/do_mounts.c                                  |    8 
 init/do_mounts.h                                  |   16 
 init/do_mounts_devfs.c                            |  137 -
 init/do_mounts_initrd.c                           |    6 
 init/do_mounts_md.c                               |    7 
 init/do_mounts_rd.c                               |    4 
 init/main.c                                       |    1 
 mm/shmem.c                                        |    5 
 mm/tiny-shmem.c                                   |    4 
 net/bluetooth/rfcomm/tty.c                        |    3 
 net/irda/ircomm/ircomm_tty.c                      |    1 
 net/irda/irnet/irnet.h                            |    1 
 sound/core/info.c                                 |    1 
 sound/core/sound.c                                |   22 
 sound/oss/soundcard.c                             |   16 
 sound/sound_core.c                                |    6 
 219 files changed, 116 insertions(+), 8447 deletions(-)


Greg Kroah-Hartman:
  devfs: Remove devfs from the kernel tree
  devfs: Remove devfs documentation from the kernel tree
  devfs: Remove devfs from the init code
  devfs: Remove devfs from the partition code
  devfs: Remove devfs_*_tape() functions from the kernel tree
  devfs: Remove devfs_mk_dir() function from the kernel tree
  devfs: Remove devfs_mk_bdev() function from the kernel tree
  devfs: Remove devfs_mk_symlink() function from the kernel tree
  devfs: Remove devfs_mk_cdev() function from the kernel tree
  devfs: Remove devfs_remove() function from the kernel tree
  devfs: Remove the miscdevice devfs_name field as it's no longer needed
  devfs: Remove the devfs_fs_kernel.h file from the tree
  devfs: Remove the gendisk devfs_name field as it's no longer needed
  devfs: Remove the uart_driver devfs_name field as it's no longer needed
  devfs: Remove the videodevice devfs_name field as it's no longer needed
  devfs: Remove the line_driver devfs_name field as it's no longer needed
  devfs: Remove the scsi_disk devfs_name field as it's no longer needed
  devfs: Remove the ide drive devfs_name field as it's no longer needed
  devfs: Remove the tty_driver devfs_name field as it's no longer needed
  devfs: Remove the mode field from usb_class_driver as it's no longer needed
  devfs: Rename TTY_DRIVER_NO_DEVFS to TTY_DRIVER_DYNAMIC_DEV
  devfs: Last little devfs cleanups throughout the kernel tree.

Re: [GIT PATCH] Remove devfs from 2.6.13

[Mike Bell]

On Fri, Sep 09, 2005 at 02:45:42PM -0700, Greg KH wrote:
> Also, if people _really_ are in love with the idea of an in-kernel
> devfs, I have posted a patch that does this in about 300 lines of code,
> called ndevfs.

Except that as I mentioned, it's broken by design. It creates yet
another incompatible naming scheme for devices, and what's worse the
devices it breaks are the ones like ALSA and the input subsystem, whose
locations are hard-coded into libraries. Unless sysfs is going to get
attributes from which the proper names could be derived, it won't ever
work.

Re: [GIT PATCH] Remove devfs from 2.6.13

[Greg KH]

On Sat, Sep 10, 2005 at 01:27:34AM -0700, Mike Bell wrote:
> On Fri, Sep 09, 2005 at 02:45:42PM -0700, Greg KH wrote:
> > Also, if people _really_ are in love with the idea of an in-kernel
> > devfs, I have posted a patch that does this in about 300 lines of code,
> > called ndevfs.
> 
> Except that as I mentioned, it's broken by design. It creates yet
> another incompatible naming scheme for devices, and what's worse the
> devices it breaks are the ones like ALSA and the input subsystem, whose
> locations are hard-coded into libraries. Unless sysfs is going to get
> attributes from which the proper names could be derived, it won't ever
> work.

I didn't say it was a "nice" solution, fully LSB compliant and all.  All
it is is a solution that can work for some people, if they just want a
small, in-kernel devfs-like solution.

And it works just fine for alsa and input devices for me, just no
subdirs :)

Anyway, I'm not offering it up for inclusion in the kernel tree at all,
but for a proof-of-concept for those who were insisting that it was
impossible to keep a devfs-like patchset out of the main kernel tree
easily.

thanks,

greg k-h

Re: [GIT PATCH] Remove devfs from 2.6.13

[Mike Bell]

On Sat, Sep 10, 2005 at 02:52:54PM -0700, Greg KH wrote:
> I didn't say it was a "nice" solution, fully LSB compliant and all.  All
> it is is a solution that can work for some people, if they just want a
> small, in-kernel devfs-like solution.

It's not a solution if it doesn't /work/. If you think this works for
anyone who likes devfs, you clearly still don't understand what said
people like about devfs in the first place.

> And it works just fine for alsa and input devices for me, just no
> subdirs :)

What version of alsa libraries are you using that can deal with the
device nodes in the root of /dev? I'm grepping the latest source code
right now and I don't see it. Or is this yet another one of those facts
you just made up? In what sense can alsa be said to work if zero alsa
programs work?

> Anyway, I'm not offering it up for inclusion in the kernel tree at
> all, but for a proof-of-concept for those who were insisting that it
> was impossible to keep a devfs-like patchset out of the main kernel
> tree easily.

You can use ndevfs, if you don't care about your device nodes working.
However that kind of defeats the purpose. To have a /working/ devfs-like
solution you need the names, and currently the only way to get those is
the devfs hooks.

Nobody is obligating you to provide a working ndevfs, but don't claim
it's a solution when it's not. A devfs-like solution whose device nodes
have random names which break programs is copying the form of devfs
(exporting nodes from kernel space) and ignoring the point of devfs.

Re: [GIT PATCH] Remove devfs from 2.6.13

[Greg KH]

On Sat, Sep 10, 2005 at 04:03:12PM -0700, Mike Bell wrote:
> On Sat, Sep 10, 2005 at 02:52:54PM -0700, Greg KH wrote:
> > I didn't say it was a "nice" solution, fully LSB compliant and all.  All
> > it is is a solution that can work for some people, if they just want a
> > small, in-kernel devfs-like solution.
> 
> It's not a solution if it doesn't /work/. If you think this works for
> anyone who likes devfs, you clearly still don't understand what said
> people like about devfs in the first place.

Said people who like devfs are lazy and don't like running userspace
programs.  They pretty much also are pretty restricted to embedded
systems.  That's all I have been able to determine so far.  Care to help
flush this profile out some?

> > And it works just fine for alsa and input devices for me, just no
> > subdirs :)
> 
> What version of alsa libraries are you using that can deal with the
> device nodes in the root of /dev? I'm grepping the latest source code
> right now and I don't see it. Or is this yet another one of those facts
> you just made up? In what sense can alsa be said to work if zero alsa
> programs work?

My applogies, I used the OSS compatible module for ALSA when I tested
this out.  Hey, might as well use 1990's style interfaces, for 1990's
style kernel features... :)

> > Anyway, I'm not offering it up for inclusion in the kernel tree at
> > all, but for a proof-of-concept for those who were insisting that it
> > was impossible to keep a devfs-like patchset out of the main kernel
> > tree easily.
> 
> You can use ndevfs, if you don't care about your device nodes working.
> However that kind of defeats the purpose. To have a /working/ devfs-like
> solution you need the names, and currently the only way to get those is
> the devfs hooks.

Hm, ok, ALSA will not work.  Can you point to anything else?  Who cares
about sound on embedded systems anyway...

> Nobody is obligating you to provide a working ndevfs, but don't claim
> it's a solution when it's not. A devfs-like solution whose device nodes
> have random names which break programs is copying the form of devfs
> (exporting nodes from kernel space) and ignoring the point of devfs.

I'm claiming that the people who insisted that keeping the devfs
patchset outside of the mainline kernel was impossible.  I show how to
do this with 3 calls to "add a node" and three calls to "remove a node",
in a total of only 2 different kernel files.  Such a patch is _easily_
maintainable for pretty much forever outside the kernel tree.  Distros
maintain patches _way_ more complex and rough than that all the time.

That is my main point about ndevfs.

thanks,

greg k-h

Re: [GIT PATCH] Remove devfs from 2.6.13

[Steven Rostedt]

On Sat, 2005-09-10 at 22:09 -0700, Greg KH wrote:

> 
> Hm, ok, ALSA will not work.  Can you point to anything else?  Who cares
> about sound on embedded systems anyway...

Hmm, a quiet PS2?  I don't think people would go for that ;-)

Not that the PS2 runs Linux, but yes there are embedded systems that do
require sound.

-- Steve

Re: [GIT PATCH] Remove devfs from 2.6.13

[Mike Bell]

On Sat, Sep 10, 2005 at 10:09:06PM -0700, Greg KH wrote:
> Said people who like devfs are lazy and don't like running userspace
> programs. 

I hardly consider myself lazy or a hater of user space programs. I've
been an early adopter running unstable series kernels and testing out
new features since long before devfs went into the kernel. In the past
I've been quick to switch over to new ways of doing things as they came
into the kernel, even when it required a fair bit of time and effort to
migrate.

What I don't like is when someone arbitrarily declares that their
half-finished project obsoletes a working one, and yet even a full year
later with a massive development community using the latest kernel
features (sometimes added specifically for that project) it isn't a full
replacement for a project that has been - in your own words -
unmaintained for years and years.

> They pretty much also are pretty restricted to embedded systems.
> That's all I have been able to determine so far.  Care to help flush
> this profile out some?

Probably because they're the people building linux systems from scratch
and caring about the size and speed of the result?

> My applogies, I used the OSS compatible module for ALSA when I tested
> this out. 

And while some input subsystem users force you to specify a device node,
this method is incompatible with hotplugging so the more advanced ones
rely on finding the input device nodes where they're supposed to be, as
they should.

> Hm, ok, ALSA will not work.  Can you point to anything else? 

See above. And of course ndevfs doesn't create the device nodes that udev
doesn't support (yes, even in 2.6.12 devfs still supported more devices
than udev on my test system). Those are just the things that bit me on
the one system I tried ndevfs on before deciding there was no way to
make it work without adding sysfs attributes.

> Who cares about sound on embedded systems anyway...

People who make audio players, SIP phones, PMPs, multimedia displays,
information kiosks, set top boxes, security monitoring devices and PA
systems, to give just a few examples of embedded systems that need sound
and are currently made with linux. And even though embedded linux is
still in its infancy, I would guess that it's responsible for more linux
systems in people's hands than most distributions.

> I'm claiming that the people who insisted that keeping the devfs
> patchset outside of the mainline kernel was impossible.  I show how to
> do this with 3 calls to "add a node" and three calls to "remove a node",
> in a total of only 2 different kernel files.  Such a patch is _easily_
> maintainable for pretty much forever outside the kernel tree.  Distros
> maintain patches _way_ more complex and rough than that all the time.

How is that anything of the sort? ndevfs doesn't work, and isn't even
remotely compatible with devfs. Yes, ndevfs is easy to maintain out of
the kernel tree. But since ndevfs has absolutely nothing to do with
devfs, that doesn't change the fact that devfs can't be maintained out
of the kernel tree. Your reasoning makes no sense.

Anyway, if things continue the way they are with intentional
devfs-breakage having moved from out-of-tree drivers to in-tree drivers,
you'll get your wish soon enough when backhanded devfs removal makes the
in-tree version useless.

Re: [GIT PATCH] Remove devfs from 2.6.13

[Kyle Moffett]

[ CC list trimmed to spare Linus and Andrew the mailbox clutter ]

On Sep 14, 2005, at 16:00:49, Mike Bell wrote:
> On Sat, Sep 10, 2005 at 10:09:06PM -0700, Greg KH wrote:
>> Said people who like devfs are lazy and don't like running  
>> userspace programs.
>
> What I don't like is when someone arbitrarily declares that their  
> half-finished project obsoletes a working one, and yet even a full  
> year later with a massive development community using the latest  
> kernel features (sometimes added specifically for that project) it  
> isn't a full
> replacement for a project that has been - in your own words -  
> unmaintained for years and years.

What exactly does devfs do that udev doesn't, exactly?  I haven't  
been able to find anything on my wide variety of hardware, although I  
will admit that there are some drivers that do not yet fully/ 
correctly use the new driver model.

>> They pretty much also are pretty restricted to embedded systems.   
>> That's all I have been able to determine so far.  Care to help  
>> flush this profile out some?
>
> Probably because they're the people building linux systems from  
> scratch and caring about the size and speed of the result?

udev isn't that big or that slow, especially not the new netlink- 
socket version, so unless you can provide a concrete example, I'm not  
entirely sure what you're talking about.

>> My applogies, I used the OSS compatible module for ALSA when I  
>> tested this out.
>
> And while some input subsystem users force you to specify a device  
> node, this method is incompatible with hotplugging so the more  
> advanced ones rely on finding the input device nodes where they're  
> supposed to be, as they should.

What makes you think specifying nodes is incompatible with  
hotplugging?  I have my USB mouse and keyboard show up as /dev/ 
gyration_mouse and /dev/macally_keyboard, and I point my little input  
event program at those.  Admittedly, X kinda gets confused when I  
unplug and those go away, but X doesn't support hotplugging anyways.

>> Hm, ok, ALSA will not work.  Can you point to anything else?
>
> See above. And of course ndevfs doesn't create the device nodes  
> that udev doesn't support (yes, even in 2.6.12 devfs still  
> supported more devices than udev on my test system).

So there are broken non-new-driver-model drivers.  If you depend on  
them (especially if you depend on them for your commercial product),  
please feel free to fix them, because otherwise they won't be, and  
they'll get more out of date with every kernel release until somebody  
deletes them because they're unmaintained.

> ...before deciding there was no way to make it work without adding  
> sysfs attributes.

See above.  Feel free to fix the driver if you need it.

>> I'm claiming that the people who insisted that keeping the devfs  
>> patchset outside of the mainline kernel was impossible.  I show  
>> how to do this with 3 calls to "add a node" and three calls to  
>> "remove a node", in a total of only 2 different kernel files.   
>> Such a patch is _easily_ maintainable for pretty much forever  
>> outside the kernel tree.  Distros maintain patches _way_ more  
>> complex and rough than that all the time.
>
> ndevfs doesn't work,

Yes it does.  It works correctly for me.

> and isn't even remotely compatible with devfs.

So?  You need to change your /dev paths _now_.  You've known that  
those paths were kinda going away for a _long_ time, so it's not like  
you haven't had time to fix your code that used them.  And if you  
need a kernel-generated /dev, then ndevfs will work (albeit with sane  
paths, as opposed to the old devfs /dev/ide/host0/bus0/... crap).

> Yes, ndevfs is easy to maintain out of the kernel tree. But since  
> ndevfs has absolutely nothing to do with devfs, that doesn't change  
> the fact that devfs can't be maintained out of the kernel tree.

devfs can't be maintained _within_ the kernel tree, let alone _out_  
of it.  Besides, it contained unfixable races, etc.

> Anyway, if things continue the way they are with intentional devfs- 
> breakage having moved from out-of-tree drivers to in-tree drivers,  
> you'll get your wish soon enough when backhanded devfs removal  
> makes the in-tree version useless.

This sentence doesn't parse, perhaps you'd like to clarify?  In any  
case, devfs is going away because it's sufficiently racy and broken  
and has been marked as DEPRECATED for a year.  udev _has_ been  
completely working for a while, even if not for the full year.


Cheers,
Kyle Moffett

--
There are two ways of constructing a software design. One way is to  
make it so simple that there are obviously no deficiencies. And the  
other way is to make it so complicated that there are no obvious  
deficiencies.  The first method is far more difficult.
   -- C.A.R. Hoare

Re: [GIT PATCH] Remove devfs from 2.6.13

[Greg KH]

On Wed, Sep 14, 2005 at 01:00:49PM -0700, Mike Bell wrote:
> On Sat, Sep 10, 2005 at 10:09:06PM -0700, Greg KH wrote:
> > Said people who like devfs are lazy and don't like running userspace
> > programs. 
> 
> I hardly consider myself lazy or a hater of user space programs. I've
> been an early adopter running unstable series kernels and testing out
> new features since long before devfs went into the kernel. In the past
> I've been quick to switch over to new ways of doing things as they came
> into the kernel, even when it required a fair bit of time and effort to
> migrate.
> 
> What I don't like is when someone arbitrarily declares that their
> half-finished project obsoletes a working one, and yet even a full year
> later with a massive development community using the latest kernel
> features (sometimes added specifically for that project) it isn't a full
> replacement for a project that has been - in your own words -
> unmaintained for years and years.

What part of devfs does udev not support?  From what I remember, the
first version of udev, a binary about 5k in size, pretty much
implemented all of what devfs did.

Remember that the main goal of udev is persistant names, which devfs can
not do at all.

> > They pretty much also are pretty restricted to embedded systems.
> > That's all I have been able to determine so far.  Care to help flush
> > this profile out some?
> 
> Probably because they're the people building linux systems from scratch
> and caring about the size and speed of the result?

Size is smaller with udev, you have a userspace program, no unswapable
kernel memory.  Speed is probably even faster, have you tried udev using
the netlink interface?

> > My applogies, I used the OSS compatible module for ALSA when I tested
> > this out. 
> 
> And while some input subsystem users force you to specify a device node,
> this method is incompatible with hotplugging so the more advanced ones
> rely on finding the input device nodes where they're supposed to be, as
> they should.

I don't understand the problem here.  input devices work just fine with
ndevfs, you just have to point your program to the proper node, as
ndevfs does not support subdirectories.

> > Hm, ok, ALSA will not work.  Can you point to anything else? 
> 
> See above.

You didn't point out any specific devices that ndevfs doesn't support.

> And of course ndevfs doesn't create the device nodes that udev
> doesn't support (yes, even in 2.6.12 devfs still supported more devices
> than udev on my test system).

What devices are lacking udev support?  I don't know of any in-kernel
devices, with the exception of isdn (for which the maintainer of that
subsystem is working on it, along with a major rewrite).

> Those are just the things that bit me on the one system I tried ndevfs
> on before deciding there was no way to make it work without adding
> sysfs attributes.

Again, which devices do not have sysfs support?  I'll fix that up.

> > Who cares about sound on embedded systems anyway...
> 
> People who make audio players, SIP phones, PMPs, multimedia displays,
> information kiosks, set top boxes, security monitoring devices and PA
> systems, to give just a few examples of embedded systems that need sound
> and are currently made with linux. And even though embedded linux is
> still in its infancy, I would guess that it's responsible for more linux
> systems in people's hands than most distributions.

That was a joke...

> > I'm claiming that the people who insisted that keeping the devfs
> > patchset outside of the mainline kernel was impossible.  I show how to
> > do this with 3 calls to "add a node" and three calls to "remove a node",
> > in a total of only 2 different kernel files.  Such a patch is _easily_
> > maintainable for pretty much forever outside the kernel tree.  Distros
> > maintain patches _way_ more complex and rough than that all the time.
> 
> How is that anything of the sort? ndevfs doesn't work, and isn't even
> remotely compatible with devfs. Yes, ndevfs is easy to maintain out of
> the kernel tree. But since ndevfs has absolutely nothing to do with
> devfs, that doesn't change the fact that devfs can't be maintained out
> of the kernel tree. Your reasoning makes no sense.

My reasoning was that people who insisted that maintaining something
like devfs outside of the kernel was impossible.  I showed that this is
not true with the 3-hour hack of ndevfs.  If you, or anyone else wants
to turn it into a "true" devfs replacement, feel free.  That was my
point.

> Anyway, if things continue the way they are with intentional
> devfs-breakage having moved from out-of-tree drivers to in-tree drivers,
> you'll get your wish soon enough when backhanded devfs removal makes the
> in-tree version useless.

Yeah, I have noticed this, my devfs-removal patch is getting smaller and
smaller every release.

Remember, devfs was marked OBSOLETE way over a year ago (and not by me).
And way back in July of 2004 I stated that it would be removed in July
of 2005.  That gave everyone over a year.  How much longer do you expect
me to wait?

thanks,

greg k-h

Re: Remove devfs from 2.6.13

[Ioan Ionita]

Kill it now and ignore these die-hard fanatics. They just can't
imagine a world in which there's no devfs to be found anywhere in the
kernel. When nostalgia takes over them, someone can just show them the
way to the kernel archives. There have been much greater changes in
the kernel than the proposed removal of a system that has become
nothing more than a fat pile of dead, stinky decomposing code, laying
around waiting for someone to burry it in the past and get rid of the
stench.

On 9/14/05, Greg KH <gregkh@suse.de> wrote:
> On Wed, Sep 14, 2005 at 01:00:49PM -0700, Mike Bell wrote:
> > On Sat, Sep 10, 2005 at 10:09:06PM -0700, Greg KH wrote:
> > > Said people who like devfs are lazy and don't like running userspace
> > > programs. 
> > 
> > I hardly consider myself lazy or a hater of user space programs. I've
> > been an early adopter running unstable series kernels and testing out
> > new features since long before devfs went into the kernel. In the past
> > I've been quick to switch over to new ways of doing things as they came
> > into the kernel, even when it required a fair bit of time and effort to
> > migrate.
> > 
> > What I don't like is when someone arbitrarily declares that their
> > half-finished project obsoletes a working one, and yet even a full year
> > later with a massive development community using the latest kernel
> > features (sometimes added specifically for that project) it isn't a full
> > replacement for a project that has been - in your own words -
> > unmaintained for years and years.
> 
> What part of devfs does udev not support?  From what I remember, the
> first version of udev, a binary about 5k in size, pretty much
> implemented all of what devfs did.
> 
> Remember that the main goal of udev is persistant names, which devfs can
> not do at all.
> 
> > > They pretty much also are pretty restricted to embedded systems.
> > > That's all I have been able to determine so far.  Care to help flush
> > > this profile out some?
> > 
> > Probably because they're the people building linux systems from scratch
> > and caring about the size and speed of the result?
> 
> Size is smaller with udev, you have a userspace program, no unswapable
> kernel memory.  Speed is probably even faster, have you tried udev using
> the netlink interface?
> 
> > > My applogies, I used the OSS compatible module for ALSA when I tested
> > > this out. 
> > 
> > And while some input subsystem users force you to specify a device node,
> > this method is incompatible with hotplugging so the more advanced ones
> > rely on finding the input device nodes where they're supposed to be, as
> > they should.
> 
> I don't understand the problem here.  input devices work just fine with
> ndevfs, you just have to point your program to the proper node, as
> ndevfs does not support subdirectories.
> 
> > > Hm, ok, ALSA will not work.  Can you point to anything else? 
> > 
> > See above.
> 
> You didn't point out any specific devices that ndevfs doesn't support.
> 
> > And of course ndevfs doesn't create the device nodes that udev
> > doesn't support (yes, even in 2.6.12 devfs still supported more devices
> > than udev on my test system).
> 
> What devices are lacking udev support?  I don't know of any in-kernel
> devices, with the exception of isdn (for which the maintainer of that
> subsystem is working on it, along with a major rewrite).
> 
> > Those are just the things that bit me on the one system I tried ndevfs
> > on before deciding there was no way to make it work without adding
> > sysfs attributes.
> 
> Again, which devices do not have sysfs support?  I'll fix that up.
> 
> > > Who cares about sound on embedded systems anyway...
> > 
> > People who make audio players, SIP phones, PMPs, multimedia displays,
> > information kiosks, set top boxes, security monitoring devices and PA
> > systems, to give just a few examples of embedded systems that need sound
> > and are currently made with linux. And even though embedded linux is
> > still in its infancy, I would guess that it's responsible for more linux
> > systems in people's hands than most distributions.
> 
> That was a joke...
> 
> > > I'm claiming that the people who insisted that keeping the devfs
> > > patchset outside of the mainline kernel was impossible.  I show how to
> > > do this with 3 calls to "add a node" and three calls to "remove a
> node",
> > > in a total of only 2 different kernel files.  Such a patch is _easily_
> > > maintainable for pretty much forever outside the kernel tree.  Distros
> > > maintain patches _way_ more complex and rough than that all the time.
> > 
> > How is that anything of the sort? ndevfs doesn't work, and isn't even
> > remotely compatible with devfs. Yes, ndevfs is easy to maintain out of
> > the kernel tree. But since ndevfs has absolutely nothing to do with
> > devfs, that doesn't change the fact that devfs can't be maintained out
> > of the kernel tree. Your reasoning makes no sense.
> 
> My reasoning was that people who insisted that maintaining something
> like devfs outside of the kernel was impossible.  I showed that this is
> not true with the 3-hour hack of ndevfs.  If you, or anyone else wants
> to turn it into a "true" devfs replacement, feel free.  That was my
> point.
> 
> > Anyway, if things continue the way they are with intentional
> > devfs-breakage having moved from out-of-tree drivers to in-tree drivers,
> > you'll get your wish soon enough when backhanded devfs removal makes the
> > in-tree version useless.
> 
> Yeah, I have noticed this, my devfs-removal patch is getting smaller and
> smaller every release.
> 
> Remember, devfs was marked OBSOLETE way over a year ago (and not by me).
> And way back in July of 2004 I stated that it would be removed in July
> of 2005.  That gave everyone over a year.  How much longer do you expect
> me to wait?
> 
> thanks,
> 
> greg k-h
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [GIT PATCH] Remove devfs from 2.6.13

[Michael Thonke]

Hello Greg,

just for understanding the problem right. Some questions.
Greg KH schrieb:

>Here are the same "delete devfs" patches that I submitted for 2.6.12.
>It rips out all of devfs from the kernel and ends up saving a lot of
>space.  Since 2.6.13 came out, I have seen no complaints about the fact
>that devfs was not able to be enabled anymore, and in fact, a lot of
>different subsystems have already been deleting devfs support for a
>while now, with apparently no complaints (due to the lack of users.)
>  
>
How could users really say/complain what brakage they have, in fact they
don't even know the relationship between all that
( e.g drivers -> devfs -> sysfs or other programs that rely on devfs)?

They aren't all developers to encrypt the "magic" bug reports/debug messages
spreading over the screen.

>I mean, how can you go wrong with deleting over 8000 lines of kernel
>code :)
>  
>
Right, it's a good/right work to remove dispensable code from kernel.
Even it makes it easier to maintain the code but what happen if
there is an "for now" an unresolved/unknown problem which no one notice 
so far?

Devfs is in for many years, why removing it in just some weeks?

>So, please pull from:
>
>Please pull from:
>	rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/
>or if master.kernel.org hasn't synced up yet:
>	master.kernel.org:/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/
>
>I've posted all of these patches before, but if people really want to look at them, they can be found at:
>	http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/
>
>Also, if people _really_ are in love with the idea of an in-kernel
>devfs, I have posted a patch that does this in about 300 lines of code,
>called ndevfs.  It is available in the archives if anyone wants to use
>that instead (it is quite easy to maintain that patch outside of the
>kernel tree, due to it only needing 3 hooks into the main kernel tree.)
>  
>
I think this is a bad solution because on the one hand you "force" to 
remove devfs due it's crappy
naming sheme and on the other hand offering to add such thing again 
which brakes ALSA and other. *confused*
Even if it has only 300 lines of code.

This is not consistent with the intention to remove devfs forever.
Either say "live with it or die" or leave it as it is.

>thanks,
>
>greg k-h
>  
>
Thanks for your patience Greg

Best regards

--
Michael Thonke

Re: [GIT PATCH] Remove devfs from 2.6.13

[Douglas McNaught]

Michael Thonke <iogl64nx@gmail.com> writes:

>>Here are the same "delete devfs" patches that I submitted for 2.6.12.
>>It rips out all of devfs from the kernel and ends up saving a lot of
>>space.  Since 2.6.13 came out, I have seen no complaints about the fact
>>that devfs was not able to be enabled anymore, and in fact, a lot of
>>different subsystems have already been deleting devfs support for a
>>while now, with apparently no complaints (due to the lack of users.)
>>  
>>
> How could users really say/complain what brakage they have, in fact they
> don't even know the relationship between all that
> ( e.g drivers -> devfs -> sysfs or other programs that rely on devfs)?

If you don't know that stuff, or aren't willing to learn and report
bugs, don't run a kernel.org kernel--stick with your distro.

> Devfs is in for many years, why removing it in just some weeks?

It's been slated for removal for quite a while, and it was completely
disabled in the last kernel release.

-Doug

Re: [GIT PATCH] Remove devfs from 2.6.13

[Greg KH]

On Sat, Sep 10, 2005 at 11:03:28AM +0200, Michael Thonke wrote:
> Hello Greg,
> 
> just for understanding the problem right. Some questions.
> Greg KH schrieb:
> 
> >Here are the same "delete devfs" patches that I submitted for 2.6.12.
> >It rips out all of devfs from the kernel and ends up saving a lot of
> >space.  Since 2.6.13 came out, I have seen no complaints about the fact
> >that devfs was not able to be enabled anymore, and in fact, a lot of
> >different subsystems have already been deleting devfs support for a
> >while now, with apparently no complaints (due to the lack of users.)
> > 
> >
> How could users really say/complain what brakage they have, in fact they
> don't even know the relationship between all that
> ( e.g drivers -> devfs -> sysfs or other programs that rely on devfs)?

Their machines would not boot.  :)

> They aren't all developers to encrypt the "magic" bug reports/debug messages
> spreading over the screen.

What do you mean?

> >I mean, how can you go wrong with deleting over 8000 lines of kernel
> >code :)
> > 
> >
> Right, it's a good/right work to remove dispensable code from kernel.
> Even it makes it easier to maintain the code but what happen if
> there is an "for now" an unresolved/unknown problem which no one notice 
> so far?
> 
> Devfs is in for many years, why removing it in just some weeks?

It's been told and widly known that it was going to be removed last
July.  In July 2004 this happened, so people have known for over a year.
How much longer do you expect me to give people?

> I think this is a bad solution because on the one hand you "force" to 
> remove devfs due it's crappy naming sheme and on the other hand
> offering to add such thing again which brakes ALSA and other.
> *confused* Even if it has only 300 lines of code.
> 
> This is not consistent with the intention to remove devfs forever.
> Either say "live with it or die" or leave it as it is.

"die."  :)

I never said that ndevfs was to be a solution for anyone, just for
people who really complained about Linux not having an in-kernel
devfs-like solution.  And if they worry about this, then they can keep
that patch outside of the main kernel tree for their distros quite
easily.

thanks,

greg k-h

Re: [GIT PATCH] Remove devfs from 2.6.13

[J.A. Magallon]

On 09.09, Greg KH wrote:
> Here are the same "delete devfs" patches that I submitted for 2.6.12.
> It rips out all of devfs from the kernel and ends up saving a lot of
> space.  Since 2.6.13 came out, I have seen no complaints about the fact
> that devfs was not able to be enabled anymore, and in fact, a lot of
> different subsystems have already been deleting devfs support for a
> while now, with apparently no complaints (due to the lack of users.)
> 
> I mean, how can you go wrong with deleting over 8000 lines of kernel
> code :)
> 
> So, please pull from:
> 
> Please pull from:
> 	rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/
> or if master.kernel.org hasn't synced up yet:
> 	master.kernel.org:/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/
> 
> I've posted all of these patches before, but if people really want to look at them, they can be found at:
> 	http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/
> 
> Also, if people _really_ are in love with the idea of an in-kernel
> devfs, I have posted a patch that does this in about 300 lines of code,
> called ndevfs.  It is available in the archives if anyone wants to use
> that instead (it is quite easy to maintain that patch outside of the
> kernel tree, due to it only needing 3 hooks into the main kernel tree.)
> 

I've been running kernel.org kernels on Mandrake since eons ago, and
since many time without devfs, just with static /dev or with udev.
I still have to find an application that has a devfs path hardcoded or
even as default, everything is like /dev/dvd, not /dev/ide/0/7/disk3...
Everythig works: sound, net, etc.

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.13-jam3 (gcc 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0))

Re: [GIT PATCH] Remove devfs from 2.6.13

[J.A. Magallon]

On 09.09, Greg KH wrote:
> Here are the same "delete devfs" patches that I submitted for 2.6.12.

Would this be accompained with deleting all the devfs compat scripts in
udev (for 069) ? ;)

Or at least a split in a different package ?

Thanks.

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.13-jam3 (gcc 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0))

Re: [GIT PATCH] Remove devfs from 2.6.13

[Greg KH]

On Sat, Sep 10, 2005 at 11:24:12PM +0000, J.A. Magallon wrote:
> 
> On 09.09, Greg KH wrote:
> > Here are the same "delete devfs" patches that I submitted for 2.6.12.
> 
> Would this be accompained with deleting all the devfs compat scripts in
> udev (for 069) ? ;)

That is only 1 file, which starts out with the following statement:
	# The use of these rules is not recommended or supported.

how much more obvious do you want us udev developers to make it?  :)

thanks,

greg k-h

Re: [GIT PATCH] Remove devfs from 2.6.13

[David Lang]

On Fri, 9 Sep 2005, Greg KH wrote:

> Date: Fri, 9 Sep 2005 14:45:42 -0700
> From: Greg KH <gregkh@suse.de>
> To: Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>
> Cc: linux-kernel@vger.kernel.org
> Subject: [GIT PATCH] Remove devfs from 2.6.13
> 
> Here are the same "delete devfs" patches that I submitted for 2.6.12.
> It rips out all of devfs from the kernel and ends up saving a lot of
> space.  Since 2.6.13 came out, I have seen no complaints about the fact
> that devfs was not able to be enabled anymore, and in fact, a lot of
> different subsystems have already been deleting devfs support for a
> while now, with apparently no complaints (due to the lack of users.)

do you really think that there have been that many people who have shifted 
to 2.6.13 in less then 2 weeks since release?

I know that you take personal offense to this code existing, but Andrew 
pointed out when you proposed these patches before that we need to be 
acareful here

David Lang

Re: [GIT PATCH] Remove devfs from 2.6.13

[Greg KH]

On Sat, Sep 10, 2005 at 05:48:05PM -0700, David Lang wrote:
> On Fri, 9 Sep 2005, Greg KH wrote:
> 
> >Date: Fri, 9 Sep 2005 14:45:42 -0700
> >From: Greg KH <gregkh@suse.de>
> >To: Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>
> >Cc: linux-kernel@vger.kernel.org
> >Subject: [GIT PATCH] Remove devfs from 2.6.13
> >
> >Here are the same "delete devfs" patches that I submitted for 2.6.12.
> >It rips out all of devfs from the kernel and ends up saving a lot of
> >space.  Since 2.6.13 came out, I have seen no complaints about the fact
> >that devfs was not able to be enabled anymore, and in fact, a lot of
> >different subsystems have already been deleting devfs support for a
> >while now, with apparently no complaints (due to the lack of users.)
> 
> do you really think that there have been that many people who have shifted 
> to 2.6.13 in less then 2 weeks since release?

Ok, how long should I wait then?

> I know that you take personal offense to this code existing, but Andrew 
> pointed out when you proposed these patches before that we need to be 
> acareful here

I know, that's fine.  But if I don't keep trying, how will it ever
happen?  :)

thanks,

greg k-h

Re: [GIT PATCH] Remove devfs from 2.6.13

[David Lang]

On Sat, 10 Sep 2005, Greg KH wrote:

> On Sat, Sep 10, 2005 at 05:48:05PM -0700, David Lang wrote:
>> On Fri, 9 Sep 2005, Greg KH wrote:
>>
>>> Here are the same "delete devfs" patches that I submitted for 2.6.12.
>>> It rips out all of devfs from the kernel and ends up saving a lot of
>>> space.  Since 2.6.13 came out, I have seen no complaints about the fact
>>> that devfs was not able to be enabled anymore, and in fact, a lot of
>>> different subsystems have already been deleting devfs support for a
>>> while now, with apparently no complaints (due to the lack of users.)
>>
>> do you really think that there have been that many people who have shifted
>> to 2.6.13 in less then 2 weeks since release?
>
> Ok, how long should I wait then?

if 2.6.13 removed the devfs config option, then I would say the code 
itself should stay until 2.6.15 or 2.6.16 (if the release schedule does 
drop down to ~2 months then it would need to be at lease .16). especially 
with so many people afraid of the 2.6 series you need to wait at least one 
full release cycle, probably two (and possibly more if they end up being 
short ones) then rip out the rest of the code for the following release.

remember that the distros don't package every kernel, they skip several 
between releases and it's not going to be until they go to try them that 
all the kinks will get worked out.

add to this the fact that many people have gotten confused about kernel 
releases and think that since 13 is odd 2.6.13 is a testing kernel and 
2.6.14 will be a stable one and so won't look at .13

note that all this assumes that the issues that people have about sysfs 
not yet being able to replace that capabilities that they are useing in 
devfs have been addressed.

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: [GIT PATCH] Remove devfs from 2.6.13

[Arjan van de Ven]

On Sat, 2005-09-10 at 23:08 -0700, David Lang wrote:
> 
> remember that the distros don't package every kernel

nor do distros use devfs :)

Re: [GIT PATCH] Remove devfs from 2.6.13

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 327 bytes --]

On Sat, 10 Sep 2005 23:08:36 PDT, David Lang said:

> remember that the distros don't package every kernel, they skip several 
> between releases and it's not going to be until they go to try them that 
> all the kinks will get worked out.

I'll bite - what distros are shipping a kernel 2.6.10 or later and still
using devfs?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [GIT PATCH] Remove devfs from 2.6.13

[David Lang]

On Sun, 11 Sep 2005 Valdis.Kletnieks@vt.edu wrote:

> On Sat, 10 Sep 2005 23:08:36 PDT, David Lang said:
>
>> remember that the distros don't package every kernel, they skip several
>> between releases and it's not going to be until they go to try them that
>> all the kinks will get worked out.
>
> I'll bite - what distros are shipping a kernel 2.6.10 or later and still
> using devfs?
>
I'll admit I don't keep track of the distros and what kernels and features 
they are useing. I think I've heard people mention gentoo, but I 
haven't verified this.

however with the thousands of linux distros out there I'd lay odds that 
_someone_ is doing it ;-)

That said, my comments about the schedule should apply to any significant 
feature, not just devfs, it just happens to be the current patch being 
discussed. If Greg hadn't asked me how long I thought he needed to wait I 
would have dropped out after my initial post, but he asked so I answered.

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: [GIT PATCH] Remove devfs from 2.6.13

[Theodore Ts'o]

On Sun, Sep 11, 2005 at 12:20:06AM -0700, David Lang wrote:
> >I'll bite - what distros are shipping a kernel 2.6.10 or later and still
> >using devfs?
> >
> I'll admit I don't keep track of the distros and what kernels and features 
> they are useing. I think I've heard people mention gentoo, but I 
> haven't verified this.

Nope, not Gentoo --- Greg KH fixed gentoo a while ago.  :-)

> however with the thousands of linux distros out there I'd lay odds that 
> _someone_ is doing it ;-)

Yes, but if none of the major distributions are doing it, then past a
certain point we should just pull the trigger and be done with it.
C'mon, devfs's impending removal has been announced for a year.  It's
not like anyone can complain that they didn't get enough warning.....

							- Ted

Re: [GIT PATCH] Remove devfs from 2.6.13

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

On Sun, 2005-09-11 at 07:02 -0400, Theodore Ts'o wrote:
> On Sun, Sep 11, 2005 at 12:20:06AM -0700, David Lang wrote:
> > >I'll bite - what distros are shipping a kernel 2.6.10 or later and still
> > >using devfs?
> > >
> > I'll admit I don't keep track of the distros and what kernels and features 
> > they are useing. I think I've heard people mention gentoo, but I 
> > haven't verified this.
> 

Why do people always remember us as using devfs, instead of being one of
the first distro's supporting it (if not the first) ? :(  I already
added support for udev to the initscripts back in Sep 2003, and added
the udev-0.2 package to the tree in Oct 2003.

> Nope, not Gentoo --- Greg KH fixed gentoo a while ago.  :-)
> 

Not entirely true, but he did start to maintain the udev package around
udev-022.


-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [GIT PATCH] Remove devfs from 2.6.13

[Greg KH]

On Sun, Sep 11, 2005 at 12:20:06AM -0700, David Lang wrote:
> On Sun, 11 Sep 2005 Valdis.Kletnieks@vt.edu wrote:
> 
> >On Sat, 10 Sep 2005 23:08:36 PDT, David Lang said:
> >
> >>remember that the distros don't package every kernel, they skip several
> >>between releases and it's not going to be until they go to try them that
> >>all the kinks will get worked out.
> >
> >I'll bite - what distros are shipping a kernel 2.6.10 or later and still
> >using devfs?
> >
> I'll admit I don't keep track of the distros and what kernels and features 
> they are useing. I think I've heard people mention gentoo, but I 
> haven't verified this.

Haha, no, Gentoo does not use devfs for it's 2.6 kernels at all.  I
should know, I'm a Gentoo developer too :)

thanks,

greg k-h

Re: [GIT PATCH] Remove devfs from 2.6.13

[Bastian Blank]

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

On Sun, Sep 11, 2005 at 03:13:53AM -0400, Valdis.Kletnieks@vt.edu wrote:
> I'll bite - what distros are shipping a kernel 2.6.10 or later and still
> using devfs?

Debian unstable

Bastian

-- 
Many Myths are based on truth
		-- Spock, "The Way to Eden",  stardate 5832.3

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [GIT PATCH] Remove devfs from 2.6.13

[CaT]

On Sun, Sep 11, 2005 at 01:35:35PM +0200, Bastian Blank wrote:
> On Sun, Sep 11, 2005 at 03:13:53AM -0400, Valdis.Kletnieks@vt.edu wrote:
> > I'll bite - what distros are shipping a kernel 2.6.10 or later and still
> > using devfs?
> 
> Debian unstable

sid can hardly be called a shippable distro. that'd be like pulling
some code at a random time out of a cvs repository that's still in
development (ie sid ;) and calling it a release version.

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

Re: [GIT PATCH] Remove devfs from 2.6.13

[Greg KH]

On Sat, Sep 10, 2005 at 11:08:36PM -0700, David Lang wrote:
> remember that the distros don't package every kernel, they skip several 
> between releases and it's not going to be until they go to try them that 
> all the kinks will get worked out.

I don't know of any major distro that ships devfs with a 2.6 kernel, do
you?

> add to this the fact that many people have gotten confused about kernel 
> releases and think that since 13 is odd 2.6.13 is a testing kernel and 
> 2.6.14 will be a stable one and so won't look at .13

Well, they should not think this, a number of us have been trying our
best to get the word out as to how the current kernel development cycle
works.

> note that all this assumes that the issues that people have about sysfs 
> not yet being able to replace that capabilities that they are useing in 
> devfs have been addressed.

Hm, that happened a long time ago...

Unless anyone else knows of anything missing?

thanks,

greg k-h

Re: [GIT PATCH] Remove devfs from 2.6.13

[linux]

> I'll bite - what distros are shipping a kernel 2.6.10 or later and still
> using devfs?

Debian.  The current Debian installer is unfortunately rather tightly
coupled to devfs; the reasons for choosing it are rooted in boot floppy
size, but the development ("unstable") install image uses 2.6.12 + devfs.

I just had to do a little dance to install it on a machine where
2.6.12 didn't recognize the SATA controller but 2.6.13 counldn't
run the installer.

Note that Debian doesn't need devfs in normal operation; it's just
a bootstrapping tool.

Re: [GIT PATCH] Remove devfs from 2.6.13

[Kyle Moffett]

On Sep 11, 2005, at 07:44:35, linux@horizon.com wrote:
>> I'll bite - what distros are shipping a kernel 2.6.10 or later and  
>> still
>> using devfs?
>
> Debian.  The current Debian installer is unfortunately rather tightly
> coupled to devfs; the reasons for choosing it are rooted in boot  
> floppy
> size, but the development ("unstable") install image uses 2.6.12 +  
> devfs.
>
> I just had to do a little dance to install it on a machine where
> 2.6.12 didn't recognize the SATA controller but 2.6.13 counldn't
> run the installer.
>
> Note that Debian doesn't need devfs in normal operation; it's just
> a bootstrapping tool.

That sounds like _exactly_ the case where the Debian folks could  
maintain
the out-of-tree ndevfs patch for a while until they got their installer
floppies and such migrated to udev.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$ L++++(+ 
++) E
W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5  
X R?
tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  !y?(-)
------END GEEK CODE BLOCK------

Re: [GIT PATCH] Remove devfs from 2.6.13

[Mike Bell]

On Sun, Sep 11, 2005 at 11:43:02AM -0400, Kyle Moffett wrote:
> That sounds like _exactly_ the case where the Debian folks could
> maintain the out-of-tree ndevfs patch for a while until they got their
> installer floppies and such migrated to udev.

Then you know nothing about the subject at hand. Moving from devfs to
ndevfs is dramatically /harder/ than moving from devfs to udev. ndevfs
is not devfs compatible in any way, shape or form.

Re: [GIT PATCH] Remove devfs from 2.6.13

[Kyle Moffett]

On Sep 14, 2005, at 16:01:24, Mike Bell wrote:
> On Sun, Sep 11, 2005 at 11:43:02AM -0400, Kyle Moffett wrote:
>> That sounds like _exactly_ the case where the Debian folks could  
>> maintain the out-of-tree ndevfs patch for a while until they got  
>> their installer floppies and such migrated to udev.
>
> Then you know nothing about the subject at hand. Moving from devfs  
> to ndevfs is dramatically /harder/ than moving from devfs to udev.  
> ndevfs is not devfs compatible in any way, shape or form.

The debian installer has devfs paths coded into it, ok, sure.  The  
reason it used devfs was so it didn't need extra userspace stuff to  
create device nodes.  It seems like the installer could be reasonably  
easily converted to use different path names without changing any  
_real_ code at all, and from there all you need to do is add the  
ndevfs patch to the kernel.  It's probably about as difficult to add  
the udev userspace stuff at the right point in the boot process (you  
still need to change all the pathnames), as it is to add the ndevfs  
patch to the kernel.  On the other hand, the latter _might_ result in  
a smaller floppy image, which is what the Debian developers really  
wanted/needed.  I suppose it would be nice if the busybox people  
added basic udev-type functionality, but it's not really all that  
necessary.

Cheers,
Kyle Moffett

--
I lost interest in "blade servers" when I found they didn't throw  
knives at people who weren't supposed to be in your machine room.
   -- Anthony de Boer