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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
