[GIT PATCH] Remove devfs from 2.6.17

[GIT PATCH] Remove devfs from 2.6.17

[Greg KH]

They are the same "delete devfs" patches that I submitted for 2.6.12 and
2.6.13 and 2.6.14 and 2.6.15 and 2.6.16.  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.)

This patchset has also been in the -mm tree, with no complaints or
issues for the past few months.

It's also been almost a full year past the date when we said we would
delete devfs from the kernel tree in the file,
Documentation/feature-removal-schedule.txt, almost two years since we
publicly announced to the world that devfs would be removed from the
kernel tree.  So I think people have had plenty of advance notice that
this was going to happen by now :)

Please pull from:
	git://git.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/Changes                             |   15 
 Documentation/DocBook/kernel-api.tmpl             |    5 
 Documentation/README.DAC960                       |    6 
 Documentation/feature-removal-schedule.txt        |   11 
 Documentation/filesystems/devfs/ChangeLog         | 1977 ---------------
 Documentation/filesystems/devfs/README            | 1959 ---------------
 Documentation/filesystems/devfs/ToDo              |   40 
 Documentation/filesystems/devfs/boot-options      |   65 
 Documentation/initrd.txt                          |   24 
 Documentation/ioctl-number.txt                    |    1 
 Documentation/kernel-parameters.txt               |    4 
 arch/cris/arch-v10/kernel/debugport.c             |    2 
 arch/cris/arch-v32/kernel/debugport.c             |    2 
 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/ip2/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                                |    6 
 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                              |   17 
 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/ide/ide-cd.c                              |    2 
 drivers/ide/ide-disk.c                            |    2 
 drivers/ide/ide-floppy.c                          |    1 
 drivers/ide/ide-probe.c                           |   11 
 drivers/ide/ide-tape.c                            |   12 
 drivers/ide/ide.c                                 |   10 
 drivers/input/serio/serio_raw.c                   |    1 
 drivers/isdn/capi/capi.c                          |    5 
 drivers/isdn/gigaset/bas-gigaset.c                |    4 
 drivers/isdn/gigaset/common.c                     |    4 
 drivers/isdn/gigaset/gigaset.h                    |    3 
 drivers/isdn/gigaset/interface.c                  |    6 
 drivers/isdn/gigaset/usb-gigaset.c                |    4 
 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                    |    8 
 drivers/message/i2o/i2o_block.c                   |    1 
 drivers/mmc/mmc_block.c                           |    4 
 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/serial/21285.c                            |    1 
 drivers/serial/8250.c                             |    1 
 drivers/serial/at91_serial.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/sunhv.c                            |    1 
 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/cdc-acm.c                       |    3 
 drivers/usb/gadget/serial.c                       |    3 
 drivers/usb/serial/usb-serial.c                   |    3 
 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                                   | 2836 ----------------------
 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/videodev2.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                                |   24 
 sound/oss/soundcard.c                             |   16 
 sound/sound_core.c                                |    6 
 198 files changed, 96 insertions(+), 8274 deletions(-)

---------------

Greg Kroah-Hartman:
      devfs: Remove devfs from the kernel tree
      devfs: Remove devfs documentation from the kernel tree
      devfs: Remove devfs from the partition code
      devfs: Remove devfs from the init code
      devfs: Remove devfs support from the serial subsystem
      devfs: Remove devfs support from the ide subsystem.
      devfs: Remove devfs support from the sound subsystem
      devfs: Remove devfs_*_tape() functions from the kernel tree
      devfs: Remove devfs_mk_dir() function from the kernel tree
      devfs: Remove devfs_mk_symlink() function from the kernel tree
      devfs: Remove devfs_mk_bdev() 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 devfs_fs_kernel.h file from the tree
      devfs: Remove the miscdevice devfs_name field as it's no longer needed
      devfs: Remove the gendisk 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 tty_driver devfs_name field 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.
      devfs: Remove it from the feature_removal.txt file

Re: [GIT PATCH] Remove devfs from 2.6.17

[Michal Piotrowski]

Hi Greg,

On 19/06/06, Greg KH <gregkh@suse.de> wrote:
[snip]
> 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/
>

devfs-remove-devfs_fs_kernel.h.patch doesn't apply clean.

[michal@ltg01-fedora linux-work2]$ quilt push devfs-feature-removal.patch
Applying patch patches/devfs-die-die-die.patch
patching file fs/Makefile
patching file fs/compat_ioctl.c
[..]
patching file drivers/video/fbmem.c
patching file fs/coda/psdev.c
patching file fs/partitions/check.c
Hunk #1 FAILED at 320.
1 out of 1 hunk FAILED -- rejects in file fs/partitions/check.c
patching file include/linux/devfs_fs_kernel.h
Patch patches/devfs-remove-devfs_remove.patch does not apply (enforce with -f)

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: [GIT PATCH] Remove devfs from 2.6.17

[Samuel Thibault]

Greg KH, le Sun 18 Jun 2006 15:13:43 -0700, a écrit :
> Since 2.6.13 came out, I have seen no complaints about the fact that
> devfs was not able to be enabled anymore,

There has been at least my complaint about udev not being able to
auto-load modules on /dev entry lookup (28th March 2006):

« Given a freshly booted linux box, hence uinput is not loaded (why
would it be, it doesn't drive any real hardware) ; what is the right
way(tm) for an application to have the uinput module loaded, so that it
can open /dev/input/uinput for emulating keypresses?

- With good-old static /dev, we could just open /dev/input/uinput
  (installed by the distribution), and thanks to a
  alias char-major-10-223 uinput
  line somewhere in /etc/modprobe.d, uinput gets auto-loaded.

- With devfs, it doesn't look like it works (/dev/misc/uinput is not
  present and opening it just like if it existed doesn't work). But I
  read in archives that it could be feasible.

- With udev, this just cannot work. As explained in an earlier thread,
  even using a special filesystem that would report the opening attempt
  to udevd wouldn't work fine since udevd takes time for creating the
  device, and hence the original program needs to be notified ; this
  becomes racy.

So what is the correct way to do it? I can see two approaches:

Using modprobe:
- try to use /dev/input/uinput ; if it succeeds, fine.
- else, if errno != ENOENT, fail
- else, (ENOENT)
  - try to call `cat /proc/sys/kernel/modprobe` uinput
  - try to use /dev/input/uinput again ; if it succeeds, fine
    - else, assume that it really wasn't compiled, and hence fail.

Triggering auto-load by creating one's own node.
- try to use /dev/input/uinput ; if it suceeds, fine.
- else, if errno != ENOENT, fail
- else, (ENOENT)
  - mknod /somewhere/safe/uinput c 10 223
  - use /somewhere/safe/uinput ; if it succeeds, fine
    - else, assume that it really wasn't compiled, and hence fail.
»

Neither solution looks good to me... Just opening /dev/input/uinput
should be sufficient, and udev doesn't let that for now.

The same situation holds for other virtual devices (loop, snd-seq-dummy,
...).

Samuel

Re: [GIT PATCH] Remove devfs from 2.6.17

[Greg KH]

On Mon, Jun 19, 2006 at 12:45:16AM +0200, Michal Piotrowski wrote:
> Hi Greg,
> 
> On 19/06/06, Greg KH <gregkh@suse.de> wrote:
> [snip]
> >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/
> >
> 
> devfs-remove-devfs_fs_kernel.h.patch doesn't apply clean.
> 
> [michal@ltg01-fedora linux-work2]$ quilt push devfs-feature-removal.patch
> Applying patch patches/devfs-die-die-die.patch
> patching file fs/Makefile
> patching file fs/compat_ioctl.c
> [..]
> patching file drivers/video/fbmem.c
> patching file fs/coda/psdev.c
> patching file fs/partitions/check.c
> Hunk #1 FAILED at 320.
> 1 out of 1 hunk FAILED -- rejects in file fs/partitions/check.c
> patching file include/linux/devfs_fs_kernel.h
> Patch patches/devfs-remove-devfs_remove.patch does not apply (enforce with 
> -f)

You need to have the other patches in my quilt tree in order to be able
to apply this one from the kernel.org directory.  I fixed this up by
hand for the git tree that I pointed Linus at.

thanks,

greg k-h

Re: [GIT PATCH] Remove devfs from 2.6.17

[Greg KH]

On Mon, Jun 19, 2006 at 01:00:41AM +0200, Samuel Thibault wrote:
> Greg KH, le Sun 18 Jun 2006 15:13:43 -0700, a ?crit :
> > Since 2.6.13 came out, I have seen no complaints about the fact that
> > devfs was not able to be enabled anymore,
> 
> There has been at least my complaint about udev not being able to
> auto-load modules on /dev entry lookup (28th March 2006):
> 
> ??Given a freshly booted linux box, hence uinput is not loaded (why
> would it be, it doesn't drive any real hardware) ; what is the right
> way(tm) for an application to have the uinput module loaded, so that it
> can open /dev/input/uinput for emulating keypresses?
> 
> - With good-old static /dev, we could just open /dev/input/uinput
>   (installed by the distribution), and thanks to a
>   alias char-major-10-223 uinput
>   line somewhere in /etc/modprobe.d, uinput gets auto-loaded.
> 
> - With devfs, it doesn't look like it works (/dev/misc/uinput is not
>   present and opening it just like if it existed doesn't work). But I
>   read in archives that it could be feasible.

But I don't think it ever worked, as you stated.

> - With udev, this just cannot work. As explained in an earlier thread,
>   even using a special filesystem that would report the opening attempt
>   to udevd wouldn't work fine since udevd takes time for creating the
>   device, and hence the original program needs to be notified ; this
>   becomes racy.
> 
> So what is the correct way to do it? I can see two approaches:

You forgot:
  - use a static /dev if you want this.
No one is forcing you to use udev :)

> Using modprobe:
> - try to use /dev/input/uinput ; if it succeeds, fine.
> - else, if errno != ENOENT, fail
> - else, (ENOENT)
>   - try to call `cat /proc/sys/kernel/modprobe` uinput
>   - try to use /dev/input/uinput again ; if it succeeds, fine
>     - else, assume that it really wasn't compiled, and hence fail.
> 
> Triggering auto-load by creating one's own node.
> - try to use /dev/input/uinput ; if it suceeds, fine.
> - else, if errno != ENOENT, fail
> - else, (ENOENT)
>   - mknod /somewhere/safe/uinput c 10 223
>   - use /somewhere/safe/uinput ; if it succeeds, fine
>     - else, assume that it really wasn't compiled, and hence fail.
> ?
> 
> Neither solution looks good to me... Just opening /dev/input/uinput
> should be sufficient, and udev doesn't let that for now.

No, just do what the distros that use udev do today, load the needed
modules at boot time, based on the hardware that is present in the
system.  This should work just fine for the uinput driver, and if not,
simply add it to the list of modules that need to be loaded every boot
(each distro has a different place to put this list), and you should be
fine.

Please realize that the method of loading a module based on the device
node number is very restrictive, and only works for a small minority of
drivers.  This is due to the wide range of hardware sharing device nodes
(do you want to load all of the possible sound drivers when you touch
the sound device node?, no, you just want it "to work automatically",
which is what happens today at boot time with udev.)

> The same situation holds for other virtual devices (loop, snd-seq-dummy,
> ...).

Yes, look at how the distros do this today for loop, they merely load it
at boot time and everyone's happy.

And this whole thing has nothing to do with devfs, as you stated above
:)

thanks,

greg k-h

Re: [GIT PATCH] Remove devfs from 2.6.17

[Samuel Thibault]

Hi,

Greg KH, le Sun 18 Jun 2006 16:12:04 -0700, a écrit :
> On Mon, Jun 19, 2006 at 01:00:41AM +0200, Samuel Thibault wrote:
> > - With udev, this just cannot work. As explained in an earlier thread,
> >   even using a special filesystem that would report the opening attempt
> >   to udevd wouldn't work fine since udevd takes time for creating the
> >   device, and hence the original program needs to be notified ; this
> >   becomes racy.
> > 
> > So what is the correct way to do it? I can see two approaches:
> 
> You forgot:
>   - use a static /dev if you want this.
> No one is forcing you to use udev :)

I can't choose the preference of the users of my program.

> > Neither solution looks good to me... Just opening /dev/input/uinput
> > should be sufficient, and udev doesn't let that for now.
> 
> No, just do what the distros that use udev do today, load the needed
> modules at boot time, based on the hardware that is present in the
> system.  This should work just fine for the uinput driver,

No hardware correspond to the uinput driver.

> and if not, simply add it to the list of modules that need to be
> loaded every boot (each distro has a different place to put this
> list), and you should be fine.

I can't ask the users of my program to do that either (actually, they
can't even do this, since they need uinput for just being able to type
things on the console...)

> Please realize that the method of loading a module based on the device
> node number is very restrictive, and only works for a small minority of
> drivers.

Agreed. But here, what is best? To explicitely load a "uinput" module or
to explicitely open "/dev/input/uinput" ?

> > The same situation holds for other virtual devices (loop, snd-seq-dummy,
> > ...).
> 
> Yes, look at how the distros do this today for loop, they merely load it
> at boot time and everyone's happy.

So distributions should load every possible virtual device?

In the debian case, it doesn't, but udev has a links.conf script that
creates a /dev/loop/0 entry, which losetup can open when looking for
loop block devices, and hence the loop module gets auto-loaded. This is
the behavior I'd expect.

> And this whole thing has nothing to do with devfs, as you stated above
> :)

Ok, but devfs had let me some hope that it would work, and udev doesn't
so much (the abovementioned links.conf file is considered hacky).

Samuel

Re: [GIT PATCH] Remove devfs from 2.6.17

[Nick Piggin]

Samuel Thibault wrote:
> Hi,
> 
> Greg KH, le Sun 18 Jun 2006 16:12:04 -0700, a écrit :
> 

>>And this whole thing has nothing to do with devfs, as you stated above
>>:)
> 
> 
> Ok, but devfs had let me some hope that it would work, and udev doesn't
> so much (the abovementioned links.conf file is considered hacky).

Could you do it with FUSE?

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [GIT PATCH] Remove devfs from 2.6.17

[H. Peter Anvin]

Samuel Thibault wrote:
> 
> There has been at least my complaint about udev not being able to
> auto-load modules on /dev entry lookup (28th March 2006):
> 
> « Given a freshly booted linux box, hence uinput is not loaded (why
> would it be, it doesn't drive any real hardware) ; what is the right
> way(tm) for an application to have the uinput module loaded, so that it
> can open /dev/input/uinput for emulating keypresses?
> 
> - With good-old static /dev, we could just open /dev/input/uinput
>   (installed by the distribution), and thanks to a
>   alias char-major-10-223 uinput
>   line somewhere in /etc/modprobe.d, uinput gets auto-loaded.
> 
> - With devfs, it doesn't look like it works (/dev/misc/uinput is not
>   present and opening it just like if it existed doesn't work). But I
>   read in archives that it could be feasible.
> 
> - With udev, this just cannot work. As explained in an earlier thread,
>   even using a special filesystem that would report the opening attempt
>   to udevd wouldn't work fine since udevd takes time for creating the
>   device, and hence the original program needs to be notified ; this
>   becomes racy.
> 

It would be nice if udev could be fed not just from the kernel, but from 
the repository of modules that are available for loading.  That may 
require additional module information.

	-hpa

Re: [GIT PATCH] Remove devfs from 2.6.17

[Joshua Hudson]

With udev, you could mknod it yourself (in your application), then open it.
That would fire up the auto-module-load.

Re: [GIT PATCH] Remove devfs from 2.6.17

[H. Peter Anvin]

Joshua Hudson wrote:
> With udev, you could mknod it yourself (in your application), then open it.
> That would fire up the auto-module-load.

Sure, but it would be even better if pointing udev to a set of modules 
(or perhaps a file generated by depmod) and have it do it all automatically.

	-hpa

Re: [GIT PATCH] Remove devfs from 2.6.17

[Greg KH]

On Sun, Jun 18, 2006 at 05:54:27PM -0700, H. Peter Anvin wrote:
> Samuel Thibault wrote:
> >
> >There has been at least my complaint about udev not being able to
> >auto-load modules on /dev entry lookup (28th March 2006):
> >
> >? Given a freshly booted linux box, hence uinput is not loaded (why
> >would it be, it doesn't drive any real hardware) ; what is the right
> >way(tm) for an application to have the uinput module loaded, so that it
> >can open /dev/input/uinput for emulating keypresses?
> >
> >- With good-old static /dev, we could just open /dev/input/uinput
> >  (installed by the distribution), and thanks to a
> >  alias char-major-10-223 uinput
> >  line somewhere in /etc/modprobe.d, uinput gets auto-loaded.
> >
> >- With devfs, it doesn't look like it works (/dev/misc/uinput is not
> >  present and opening it just like if it existed doesn't work). But I
> >  read in archives that it could be feasible.
> >
> >- With udev, this just cannot work. As explained in an earlier thread,
> >  even using a special filesystem that would report the opening attempt
> >  to udevd wouldn't work fine since udevd takes time for creating the
> >  device, and hence the original program needs to be notified ; this
> >  becomes racy.
> >
> 
> It would be nice if udev could be fed not just from the kernel, but from 
> the repository of modules that are available for loading.  That may 
> require additional module information.

There's no reason it could not be, but usually a simple, "modprobe loop"
works good enough for everyone :)

thanks,

greg k-h

Re: [GIT PATCH] Remove devfs from 2.6.17

[Greg KH]

On Mon, Jun 19, 2006 at 01:35:08AM +0200, Samuel Thibault wrote:
> Hi,
> 
> Greg KH, le Sun 18 Jun 2006 16:12:04 -0700, a ?crit :
> > On Mon, Jun 19, 2006 at 01:00:41AM +0200, Samuel Thibault wrote:
> > > - With udev, this just cannot work. As explained in an earlier thread,
> > >   even using a special filesystem that would report the opening attempt
> > >   to udevd wouldn't work fine since udevd takes time for creating the
> > >   device, and hence the original program needs to be notified ; this
> > >   becomes racy.
> > > 
> > > So what is the correct way to do it? I can see two approaches:
> > 
> > You forgot:
> >   - use a static /dev if you want this.
> > No one is forcing you to use udev :)
> 
> I can't choose the preference of the users of my program.
> 
> > > Neither solution looks good to me... Just opening /dev/input/uinput
> > > should be sufficient, and udev doesn't let that for now.
> > 
> > No, just do what the distros that use udev do today, load the needed
> > modules at boot time, based on the hardware that is present in the
> > system.  This should work just fine for the uinput driver,
> 
> No hardware correspond to the uinput driver.

I'm not familiar with the uinput driver, but you might want to look at
how all of the other input drivers are autoloaded by udev based on
module aliases and see if that will work for you too.

Or just tell your users to make sure that they have the uinput driver
loaded, and look into the distro's documentation for how to have it
automatically loaded at boot time (they all provide this functionality
for modules that don't have a hardware backing device.)

> > and if not, simply add it to the list of modules that need to be
> > loaded every boot (each distro has a different place to put this
> > list), and you should be fine.
> 
> I can't ask the users of my program to do that either (actually, they
> can't even do this, since they need uinput for just being able to type
> things on the console...)

I'm not aware of what your program is, but why not do it for them in
your program startup logic (yes, it requires root access, but that's a
requirement).

> > Please realize that the method of loading a module based on the device
> > node number is very restrictive, and only works for a small minority of
> > drivers.
> 
> Agreed. But here, what is best? To explicitely load a "uinput" module or
> to explicitely open "/dev/input/uinput" ?

Well as trying to open /dev/input/uinput will not cause anything to load
anymore (due to devfs not doing this, and udev systems not allowing this
to happen), I suggest loading the uinput module.

> > > The same situation holds for other virtual devices (loop, snd-seq-dummy,
> > > ...).
> > 
> > Yes, look at how the distros do this today for loop, they merely load it
> > at boot time and everyone's happy.
> 
> So distributions should load every possible virtual device?

Within reason, it seems like they do at times.

> In the debian case, it doesn't, but udev has a links.conf script that
> creates a /dev/loop/0 entry, which losetup can open when looking for
> loop block devices, and hence the loop module gets auto-loaded. This is
> the behavior I'd expect.

Perhaps you can just create a uinput script that does this.

Or just add that device node to the /lib/udev/devices/ directory, and it
will be restored at every boot, then when your user opens it, the proper
module will be automatically loaded.  That is what that directory is
there for (as well as for device nodes that don't play nice with udev or
can't for whatever reason.)

> > And this whole thing has nothing to do with devfs, as you stated above
> > :)
> 
> Ok, but devfs had let me some hope that it would work, and udev doesn't
> so much (the abovementioned links.conf file is considered hacky).

As devfs has not been maintained in over 4 years, I don't see how not
removing it will help this situation out at all for you, sorry.

I suggest taking this topic to the linux-hotplug-devel mailing list if
you still have issues loading the uinput module at boot time for your
systems that run udev.

thanks,

greg k-h

Re: [GIT PATCH] Remove devfs from 2.6.17

[Will Dyson]

On 6/18/06, H. Peter Anvin <hpa@zytor.com> wrote:
> Joshua Hudson wrote:
> > With udev, you could mknod it yourself (in your application), then open it.
> > That would fire up the auto-module-load.
>
> Sure, but it would be even better if pointing udev to a set of modules
> (or perhaps a file generated by depmod) and have it do it all automatically.

Providing the information about what devices a virtual driver will
register when loaded seems like a good idea.

Something like the following occurs to me. But it doesn't deal with
loop's ability to register a different number of minors based on a
module parameter. Not really sure what to do about that.

Going in this direction is also a further impediment to dynamicly
assigned device numbers.

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 9c3b94e..b933f3f 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1205,6 +1205,18 @@ static struct block_device_operations lo
 	.ioctl =	lo_ioctl,
 };

+static struct virtual_device_table loop_virt_tbl= {
+	{LOOP_MAJOR, 0, 1},
+	{LOOP_MAJOR, 1, 1},
+	{LOOP_MAJOR, 2, 1},
+	{LOOP_MAJOR, 3, 1},
+	{LOOP_MAJOR, 4, 1},
+	{LOOP_MAJOR, 5, 1},
+	{LOOP_MAJOR, 6, 1},
+	{LOOP_MAJOR, 7, 1},
+	{}
+};
+
 /*
  * And now the modules code and kernel interface.
  */
@@ -1212,6 +1224,7 @@ module_param(max_loop, int, 0);
 MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-256)");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS_BLOCKDEV_MAJOR(LOOP_MAJOR);
+MODULE_DEVICE_TABLE (virtual, loop_virt_tbl);

 int loop_register_transfer(struct loop_func_table *funcs)
 {
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index f697770..f4a21d0 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -297,4 +297,16 @@ struct input_device_id {
 	kernel_ulong_t driver_info;
 };

+/*
+ * Declare the intention of a driver to register a virtual
+ * device upon loading.
+ */
+struct virtual_device_id {
+	__u32 major;
+	__u32 minor;
+	__u8 type; /* 0 for char, 1 for block */
+
+	kernel_ulong_t driver_info;
+}
+
 #endif /* LINUX_MOD_DEVICETABLE_H */


-- 
Will Dyson

Re: [GIT PATCH] Remove devfs from 2.6.17

[Alexander E. Patrakov]

Will Dyson wrote:
> On 6/18/06, H. Peter Anvin <hpa@zytor.com> wrote:
>> Joshua Hudson wrote:
>> > With udev, you could mknod it yourself (in your application), then 
>> open it.
>> > That would fire up the auto-module-load.
>>
>> Sure, but it would be even better if pointing udev to a set of modules
>> (or perhaps a file generated by depmod) and have it do it all 
>> automatically.
> 
> Providing the information about what devices a virtual driver will
> register when loaded seems like a good idea.

Why? This information is currently useless. What you want is that something 
knows that you want this driver to be loaded. So, everything you need is one line:

MODULE_ALIAS("virtual_dev");

(add this to loop, nbd, ppp_generic, uinput, dm-mod and other "virtual" drivers 
of your choice)

and the initscript that does a "modprobe virtual_dev" to catch them all.

-- 
Alexander E. Patrakov

Re: [GIT PATCH] Remove devfs from 2.6.17

[Samuel Thibault]

Hi,

Greg KH, le Sun 18 Jun 2006 20:22:59 -0700, a écrit :
> > No hardware correspond to the uinput driver.
> 
> I'm not familiar with the uinput driver, but you might want to look at
> how all of the other input drivers are autoloaded by udev based on
> module aliases and see if that will work for you too.

They're autoloaded because they correspond to real hardware. uinput
doesn't.

> Or just tell your users to make sure that they have the uinput driver
> loaded,

They can't, since without it they can't even type things.

> > > and if not, simply add it to the list of modules that need to be
> > > loaded every boot (each distro has a different place to put this
> > > list), and you should be fine.
> > 
> > I can't ask the users of my program to do that either (actually, they
> > can't even do this, since they need uinput for just being able to type
> > things on the console...)
> 
> I'm not aware of what your program is,

It's a daemon for letting blind user use their braille device
as output device and keyboard. And for beginners this is
yet-another-difficult-thing-to-remember-to-do-after-installation.

> but why not do it for them in your program startup logic (yes, it
> requires root access, but that's a requirement).

That's what we actually do. The root requirement is not a problem since
the program needs to be able to read the console anyway.

But the root requirement _is_ a problem for other cases. When I want
to use a soft synthesizer (qsynth) for midi applications for instance
(because my soundboard has no synth), I have to modprobe snd-seq-dummy
as root, which is tedious (yes I could have it always auto-loaded),
while I could very well have configured an alias between /dev/snd/seq
and snd-seq-dummy, so that just running qsynth as user would just work.

> > > Please realize that the method of loading a module based on the device
> > > node number is very restrictive, and only works for a small minority of
> > > drivers.
> > 
> > Agreed. But here, what is best? To explicitely load a "uinput" module or
> > to explicitely open "/dev/input/uinput" ?
> 
> Well as trying to open /dev/input/uinput will not cause anything to load
> anymore (due to devfs not doing this, and udev systems not allowing this
> to happen), I suggest loading the uinput module.

That's what we ended up to do. In this case, this is fine (since
only one module provides the uinput facility), but in the "seq" case
explained above, this can't work (the qsynth application can't know
whether it should load alsa's dummy device or oss's or...)

> > > > The same situation holds for other virtual devices (loop, snd-seq-dummy,
> > > > ...).
> > > 
> > > Yes, look at how the distros do this today for loop, they merely load it
> > > at boot time and everyone's happy.
> > 
> > So distributions should load every possible virtual device?
> 
> Within reason, it seems like they do at times.

I can see at least dummy_hcd, loop, snd-seq-dummy, snd-dummy, dummy (net
driver), dummycon, and uinput. This might put quite a lot of confusion
in user's mind ("Oh? I have a USB host?!").

> > In the debian case, it doesn't, but udev has a links.conf script that
> > creates a /dev/loop/0 entry, which losetup can open when looking for
> > loop block devices, and hence the loop module gets auto-loaded. This is
> > the behavior I'd expect.
> 
> Perhaps you can just create a uinput script that does this.

That's fine for me, but as I said this is considered hacky (the header
of links.conf is "This file does not exist. Please do not ask the debian
maintainer about it. You may use it to do strange and wonderful things,
at your risk.")

Samuel

Re: [GIT PATCH] Remove devfs from 2.6.17

[Samuel Thibault]

Greg KH, le Sun 18 Jun 2006 20:15:21 -0700, a écrit :
> On Sun, Jun 18, 2006 at 05:54:27PM -0700, H. Peter Anvin wrote:
> > It would be nice if udev could be fed not just from the kernel, but from 
> > the repository of modules that are available for loading.  That may 
> > require additional module information.
> 
> There's no reason it could not be, but usually a simple, "modprobe loop"
> works good enough for everyone :)

Not for non-root people. (And yes, they may want to do non-root things
with such virtual devices, in the dummy sequencer case for instance).

Samuel

Re: [GIT PATCH] Remove devfs from 2.6.17

[Marcel Holtmann]

Hi Samuel,

> > Or just tell your users to make sure that they have the uinput driver
> > loaded,
> 
> They can't, since without it they can't even type things.

if you install a program or a driver that needs uinput loaded, then you
have a clean requirement. So simply add a "modprobe uinput" to its init
script.

Look at the TUN/Tap driver which has the same problem. The boot up
scripts of various daemons (for example OpenVPN etc.) are making sure
that the driver is loaded.

Regards

Marcel

Re: [GIT PATCH] Remove devfs from 2.6.17

[Samuel Thibault]

Marcel Holtmann, le Mon 19 Jun 2006 11:30:31 +0200, a écrit :
> > > Or just tell your users to make sure that they have the uinput driver
> > > loaded,
> > 
> > They can't, since without it they can't even type things.
> 
> if you install a program or a driver that needs uinput loaded, then you
> have a clean requirement. So simply add a "modprobe uinput" to its init
> script.
> 
> Look at the TUN/Tap driver which has the same problem. The boot up
> scripts of various daemons (for example OpenVPN etc.) are making sure
> that the driver is loaded.

And vtun's script in debian doesn't, so that I had to load it by hand.
Don't justify lack of support thanks to corrections that people had to
add ;)

The problem I'm raising is that with udev we seem to be heading to
asking every program to know which module it should load by hand before
being able to use a /dev entry. This looks odd to me (why not opening
the /dev entry itself shouldn't autoload the driver?).

Samuel

Re: [GIT PATCH] Remove devfs from 2.6.17

[Marcel Holtmann]

Hi Samuel,

> > > They can't, since without it they can't even type things.
> > 
> > if you install a program or a driver that needs uinput loaded, then you
> > have a clean requirement. So simply add a "modprobe uinput" to its init
> > script.
> > 
> > Look at the TUN/Tap driver which has the same problem. The boot up
> > scripts of various daemons (for example OpenVPN etc.) are making sure
> > that the driver is loaded.
> 
> And vtun's script in debian doesn't, so that I had to load it by hand.
> Don't justify lack of support thanks to corrections that people had to
> add ;)
> 
> The problem I'm raising is that with udev we seem to be heading to
> asking every program to know which module it should load by hand before
> being able to use a /dev entry. This looks odd to me (why not opening
> the /dev entry itself shouldn't autoload the driver?).

I don't see any problems that every program knows what kernel module it
requires. In case of misc character devices with dynamic minor numbers,
I would actually prefer that the application or an init scripts triggers
the module loading. Unless the module is loaded, the kernel doesn't know
anything about this device.

Regards

Marcel

Re: [GIT PATCH] Remove devfs from 2.6.17

[Daniel Barkalow]

On Mon, 19 Jun 2006, Alexander E. Patrakov wrote:

> Will Dyson wrote:
> > Providing the information about what devices a virtual driver will
> > register when loaded seems like a good idea.
> 
> Why? This information is currently useless. What you want is that something
> knows that you want this driver to be loaded.

The point is that you *don't* want those modules to be loaded. What you 
want is for the kernel to know that those modules are available, and 
therefore mention that drivers could be found for those devices, and 
therefore udev would create the device nodes for them, even though the 
kernel doesn't contain a module that drives them yet.

If something actually opens the device node, the module will be loaded, 
but until then it isn't using up resources.

	-Daniel
*This .sig left intentionally blank*

Re: [GIT PATCH] Remove devfs from 2.6.17

[H. Peter Anvin]

Daniel Barkalow wrote:
> On Mon, 19 Jun 2006, Alexander E. Patrakov wrote:
> 
>> Will Dyson wrote:
>>> Providing the information about what devices a virtual driver will
>>> register when loaded seems like a good idea.
>> Why? This information is currently useless. What you want is that something
>> knows that you want this driver to be loaded.
> 
> The point is that you *don't* want those modules to be loaded. What you 
> want is for the kernel to know that those modules are available, and 
> therefore mention that drivers could be found for those devices, and 
> therefore udev would create the device nodes for them, even though the 
> kernel doesn't contain a module that drives them yet.
> 

The kernel doesn't need to know.  udev needs to know.

	-hpa