Gary Shea writes:
> Richard Gooch (rgooch@xxxxxxxxxxxxxxx) wrote:
> > Ah. Perhaps your system boot scripts copy the state from
> > /lib/dev-state into /dev. That's actually unwise, since there is no
> > distinction between devfs/devfsd created inodes and normal process
> > created inodes. It would be interesting to know if this indiscriminate
> > copying is actually happening. It would be nice to know what the
> > problem was.
> >
> > I'm currently finishing off the persistence management in devfsd,
> > which will do this stuff properly. It will require v1.2 of the devfs
> > core (already in kernel 2.4.17-pre1). Expect a new version of devfsd
> > soon.
>
> Ah, ok... I dug around a bit and found....
>
> # copy /lib/dev-state before starting devfsd to avoid accidentally
> # triggering devfsd actions (like module loading)
> if [ -d /lib/dev-state ]; then
> cp -af /lib/dev-state/* /dev > /dev/null 2>&1
> fi
> action "Running DevFs deamon" devfsd /dev
> if [ -f /etc/sysconfig/mouse ];then
> . /etc/sysconfig/mouse
> device=`echo $device | sed -e 's/psaux/misc\/psaux/' -e
> 's/ttyS\(.\)/tts\/\1/g'`
> if [ -n "$device" ]; then
> rm -f /dev/mouse
> ln -s /dev/$device /dev/mouse
> fi
> fi
>
> Yuck. So can I get rid of the copy or is there something to reckon
> with in the comment about 'triggering devfsd actions'? Sorry about
> the lame questions... I'm in over my head here.
The comment is saying that the copy is best done before starting
devfsd, rather than afterwards. However, removing the copy code
entirely is OK too (you might find some entries are no longer in /dev
because they haven't been restored by this copy, but you know that
anyway).
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|