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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/