Re: devfs unable to handle permission: 2.4.17-pre[4,5] /ALSA-0.9.0beta[9,10]

[Richard Gooch <rgooch@ras.ucalgary.ca>]

Marcelo Tosatti writes:
> 
> 
> On Sun, 9 Dec 2001, Roman Zippel wrote:
> 
> > Hi,
> > 
> > Richard Gooch wrote:
> > 
> > > There are some broken boot scripts (modelled after the long obsolete
> > > rc.devfs script)
> > 
> > Which is still included in the kernel tree and at least Mandrake is
> > currently using it.
> > There were no signs of deprecation, so people are legally using it.

I mentioned it somewhere, but it might not have been on the list. It
was a long time ago.

> > > This is not actually a problem for leaf nodes, since the user-space
> > > created device nodes will still work. It just results in a warning
> > > message.
> > 
> > Wrong, these are not just warning messages, the driver API has changed.
> > 
> > > So, in this case, the device nodes that the user wants to use will
> > > still be there (created by the boot script) and will work fine.
> > 
> > Except the dynamic update of device nodes won't happen anymore, so it
> > affects also all leaf nodes in the directories (e.g. partition entries
> > won't be created/removed anymore). Events won't be created for these
> > nodes as well, so configurations depending on this are broken as well.
>
> Richard, 
> 
> Are the above problems really introduced by the changes ? 

Yes, although I still think it's not a common problem. In general, if
you are tarring and untarring inodes, you take the whole directory and
put it all back again. Even the partitioning event is a corner case,
since you're most likely to install a new drive (and thus have no
inodes to "restore") and then partition. And even the obsolete
rc.devfs only saved away inodes which had been changed, not
everything.

However, if this concerns you, I can send a patch that effectively
restores the old behaviour for directories. It's just a matter of
grabbing the right lock, fiddling a flag and returning a different
entry. But I definately want to keep a warning message. I want there
to be some pain for broken or really obsolete configurations.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca