Re: [GIT PATCH] Remove devfs from 2.6.17

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


_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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



_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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


_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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




_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel