Re: udev: missing /dev/snd, /dev/sound, and others

Am Sonntag, 23. April 2006 12:10 schrieb Terry Mackintosh:
> Hi all
>
> Build is ROCK trunk from about a month ago, with a few patches and some
> package directories updated to current that were failing to build.
>
> Target is Generic.
> Optimization is for PIII
> First install victim is a PIII.
>
> After several fixes all but 38 packages built, and none of the failures
> looked to be important, save for maybe svgalib.
>
> Build host was ROCK 2.0.3 Generic, PII, w/2.6 kernel.
>
> While I spent some time reading man pages, I still do not understand
> udev hardly at all.

I suggest to update udev as well. It has been worked on recently, and you 
wouldn't want to fix the same bug twice.

>
> Anyway, the first thing I notice is no sound: no /dev/snd or /dev/sound
> Although the sound card is found and there is much stuff about the sound
> card in /sys.

That said, I'd like to add udev 0.88 works fine here (using soundcard, dri, 
fb,
usb printer & mouse and video devices). Yet I don't know much about udev 
internals, so here's only some general tips:

- make sure kernel modules for your drivers are loaded (I probably don't have 
to tell you that).
- udev as used in ROCK receives events about added devices over a kernel- to 
user-space netlink, which has to be enabled in your kernel (it is in default 
ROCK configurations - see linux: make menuconfig -> device drivers -> 
connector).
- with udevmonitor you can see the kernel and udev event sequence: start 
udevmonitor and unload/load e.g. the sound module. You'll be able to see at 
least whether udevd receives any events. 

>
> Upon checking the /etc/udev/* stuff, it all looks good as far as I can
> tell.
>
> I did notice that both udev and devfs were being started, so removed
> devfs from the rc2.d directory.
>
> Other things are also apparently missing, as when X starts, it fails due
> to no /dev/fb or some such.

Was udevd running when the respective modules where loaded? If not you'll have 
to use udevtrigger to request kernel devices events for this so-called 
coldplug case (devices already present in the kernel before udevd was 
started). Note udevtrigger is included only in recent udev releases.

>
> Also, the /dev directory is very cluttered with lots of tty* and pt*
> files, most of which I'm sure I don't need, right?

Again, see linux: make menuconfig -> device drivers -> character devices -> 
Legacy (BSD) PTY support

CONFIG_LEGACY_PTYS:
Linux has traditionally used the BSD-like names /dev/ptyxx                                     
for masters and /dev/ttyxx for slaves of pseudo
terminals. This scheme has a number of problems, including
security.  This option enables these legacy devices; on most
systems, it is safe to say N.

We should probably get rid of this option in default configurations; yet noone 
seems to have tried if any important program relies on it.

Hope that helps,
	Stefan Fiedler

P.S.: Did you really sent this email on April, 23.? It arrived here just 
today :S

>
> Any help much appreciated, thanks.