Hi.
At least since 2.4.17-pre4 and -pre5 devfs is not handling permissions in the
right way with ALSA:
rene@jackson:/dev > l dsp sound/dsp
ls: sound/dsp: Permission denied
lr-xr-xr-x 1 root root 9 Dec 7 00:14 dsp -> sound/dsp
rene@jackson:/dev > cd sound/
bash: cd: sound/: Permission denied
rene@jackson:/dev >
rene@jackson:/dev > l snd
ls: snd/..: Permission denied
ls: snd/.: Permission denied
ls: snd/controlC0: Permission denied
ls: snd/controlC1: Permission denied
ls: snd/timer: Permission denied
ls: snd/midiC0D0: Permission denied
ls: snd/pcmC0D2p: Permission denied
ls: snd/pcmC0D1c: Permission denied
ls: snd/pcmC0D0p: Permission denied
ls: snd/pcmC0D0c: Permission denied
ls: snd/midiC1D0: Permission denied
ls: snd/pcmC1D0p: Permission denied
ls: snd/pcmC1D0c: Permission denied
total 0
They all have 666 (or 777 for dirs)! It is possible to this as root.
Also loading the modules gives me:
Dec 7 00:31:58 jackson kernel: devfs: devfs_register(unknown): could not append to parent, err: -17
k33p h4ck1n6
Ren?
--
Ren? Rebe (Registered Linux user: #248718 <http://counter.li.org>)
eMail: [email protected]
[email protected]
Homepage: http://www.tfh-berlin.de/~s712059/index.html
Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.
Rene Rebe writes:
> At least since 2.4.17-pre4 and -pre5 devfs is not handling
> permissions in the right way with ALSA:
Please define what is the "right way".
> rene@jackson:/dev > l dsp sound/dsp
> ls: sound/dsp: Permission denied
> lr-xr-xr-x 1 root root 9 Dec 7 00:14 dsp -> sound/dsp
> rene@jackson:/dev > cd sound/
> bash: cd: sound/: Permission denied
> rene@jackson:/dev >
>
> rene@jackson:/dev > l snd
> ls: snd/..: Permission denied
> ls: snd/.: Permission denied
> ls: snd/controlC0: Permission denied
> ls: snd/controlC1: Permission denied
> ls: snd/timer: Permission denied
> ls: snd/midiC0D0: Permission denied
> ls: snd/pcmC0D2p: Permission denied
> ls: snd/pcmC0D1c: Permission denied
> ls: snd/pcmC0D0p: Permission denied
> ls: snd/pcmC0D0c: Permission denied
> ls: snd/midiC1D0: Permission denied
> ls: snd/pcmC1D0p: Permission denied
> ls: snd/pcmC1D0c: Permission denied
> total 0
>
> They all have 666 (or 777 for dirs)!
Are you saying this is good or bad?
> It is possible to this as root.
It's possible to do what? List the inodes? Open then? What?
> Also loading the modules gives me:
> Dec 7 00:31:58 jackson kernel: devfs: devfs_register(unknown): could not append to parent, err: -17
Two possibilities:
- the module is trying to register "unknown" twice. The old devfs core
was forgiving about this (although it was always a driver bug to
attempt to create a duplicate). The new core won't let you do that.
Error 17 is EEXIST. Please fix the driver
- something in user-space created the "unknown" inode before the
driver could create it. This is a configuration bug. It seems
Mandrake has boot scripts which indiscriminately "restore" inodes in
/dev. This is a bug, because they also restore inodes created by the
drivers, whereas they should only be restoring admin-created inodes.
Grab devfsd-v1.3.20 which has the RESTORE directive which does this
properly, and blow away the part of the Mandrake boot scripts which
are causing the problem
FYI: what happens now with duplicates is that the old entry remains,
and the new one is discarded. If you really are creating the same
entry, there should be no harm, just that annoying message.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Thu, 6 Dec 2001 23:09:14 -0700
Richard Gooch <[email protected]> wrote:
> Rene Rebe writes:
> > At least since 2.4.17-pre4 and -pre5 devfs is not handling
> > permissions in the right way with ALSA:
>
> Please define what is the "right way".
Sorry I toght the commands wabout would be enought:
As root they are listable and read and writeable (for examples via ls -l,
cat /dev/dsp > ~/my-speach.snd or cat ~/my-speach.snd > /dev/dsp), ussing
mpg123 ...
> > rene@jackson:/dev > l dsp sound/dsp
> > ls: sound/dsp: Permission denied
> > lr-xr-xr-x 1 root root 9 Dec 7 00:14 dsp -> sound/dsp
> > rene@jackson:/dev > cd sound/
> > bash: cd: sound/: Permission denied
> > rene@jackson:/dev >
> >
> > rene@jackson:/dev > l snd
> > ls: snd/..: Permission denied
> > ls: snd/.: Permission denied
> > ls: snd/controlC0: Permission denied
> > ls: snd/controlC1: Permission denied
> > ls: snd/timer: Permission denied
> > ls: snd/midiC0D0: Permission denied
> > ls: snd/pcmC0D2p: Permission denied
> > ls: snd/pcmC0D1c: Permission denied
> > ls: snd/pcmC0D0p: Permission denied
> > ls: snd/pcmC0D0c: Permission denied
> > ls: snd/midiC1D0: Permission denied
> > ls: snd/pcmC1D0p: Permission denied
> > ls: snd/pcmC1D0c: Permission denied
> > total 0
> >
> > They all have 666 (or 777 for dirs)!
>
> Are you saying this is good or bad?
This is good. The permissions of the files are correct (everyone can use
sound), but I can (as you see in the command's output) neither access nor
read/write them as normal user - but all this works as root.
> > It is possible to this as root.
>
> It's possible to do what? List the inodes? Open then? What?
Yes. All this is possible as root but not using anothe UID.
> > Also loading the modules gives me:
> > Dec 7 00:31:58 jackson kernel: devfs: devfs_register(unknown): could not append to parent, err: -17
>
> Two possibilities:
>
> - the module is trying to register "unknown" twice. The old devfs core
> was forgiving about this (although it was always a driver bug to
> attempt to create a duplicate). The new core won't let you do that.
> Error 17 is EEXIST. Please fix the driver
>
> - something in user-space created the "unknown" inode before the
> driver could create it. This is a configuration bug. It seems
> Mandrake has boot scripts which indiscriminately "restore" inodes in
> /dev. This is a bug, because they also restore inodes created by the
I do not restore devices-nodes un reboot.
> drivers, whereas they should only be restoring admin-created inodes.
> Grab devfsd-v1.3.20 which has the RESTORE directive which does this
> properly, and blow away the part of the Mandrake boot scripts which
> are causing the problem
I use the devfsd.conf to configure the permission when a device registers.
> FYI: what happens now with duplicates is that the old entry remains,
> and the new one is discarded. If you really are creating the same
> entry, there should be no harm, just that annoying message.
The device-nodes seems to be all there they work as root, but not as normal
user. But it seems to be a ALSA issue, because only the ALSA nodes have this
strange behaviour ... ?
> Regards,
>
> Richard....
> Permanent: [email protected]
> Current: [email protected]
Have to leave now - can respond again in 8 hours ...
k33p h4ck1n6
Ren?
--
Ren? Rebe (Registered Linux user: #248718 <http://counter.li.org>)
eMail: [email protected]
[email protected]
Homepage: http://www.tfh-berlin.de/~s712059/index.html
Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.
Hi,
On Thu, 6 Dec 2001, Richard Gooch wrote:
> Two possibilities:
>
> - the module is trying to register "unknown" twice. The old devfs core
> was forgiving about this (although it was always a driver bug to
> attempt to create a duplicate). The new core won't let you do that.
> Error 17 is EEXIST. Please fix the driver
>
> - something in user-space created the "unknown" inode before the
> driver could create it. This is a configuration bug.
Option 3:
Turn a user generated entry into a kernel generated one and return 0.
Prepopulating devfs was a valid option so far, you cannot simply change
this during a stable kernel release.
bye, Roman
Roman Zippel writes:
> Hi,
>
> On Thu, 6 Dec 2001, Richard Gooch wrote:
>
> > Two possibilities:
> >
> > - the module is trying to register "unknown" twice. The old devfs core
> > was forgiving about this (although it was always a driver bug to
> > attempt to create a duplicate). The new core won't let you do that.
> > Error 17 is EEXIST. Please fix the driver
> >
> > - something in user-space created the "unknown" inode before the
> > driver could create it. This is a configuration bug.
>
> Option 3:
> Turn a user generated entry into a kernel generated one and return
> 0. Prepopulating devfs was a valid option so far, you cannot simply
> change this during a stable kernel release.
Well, no, it was never a valid option. It was always a bug. In any
case, the stricter behaviour isn't preventing people from using their
drivers, it's just issuing a warning. The user-space created device
node still works.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Rene Rebe writes:
> On Thu, 6 Dec 2001 23:09:14 -0700
> Richard Gooch <[email protected]> wrote:
>
> > Rene Rebe writes:
> > > At least since 2.4.17-pre4 and -pre5 devfs is not handling
> > > permissions in the right way with ALSA:
[...]
> > > rene@jackson:/dev > l dsp sound/dsp
> > > ls: sound/dsp: Permission denied
> > > lr-xr-xr-x 1 root root 9 Dec 7 00:14 dsp -> sound/dsp
> > > rene@jackson:/dev > cd sound/
> > > bash: cd: sound/: Permission denied
> > > rene@jackson:/dev >
> > >
> > > rene@jackson:/dev > l snd
> > > ls: snd/..: Permission denied
> > > ls: snd/.: Permission denied
> > > ls: snd/controlC0: Permission denied
> > > ls: snd/controlC1: Permission denied
> > > ls: snd/timer: Permission denied
> > > ls: snd/midiC0D0: Permission denied
> > > ls: snd/pcmC0D2p: Permission denied
> > > ls: snd/pcmC0D1c: Permission denied
> > > ls: snd/pcmC0D0p: Permission denied
> > > ls: snd/pcmC0D0c: Permission denied
> > > ls: snd/midiC1D0: Permission denied
> > > ls: snd/pcmC1D0p: Permission denied
> > > ls: snd/pcmC1D0c: Permission denied
> > > total 0
> > >
> > > They all have 666 (or 777 for dirs)!
Are you positive the directory has 777 permissions?
Thomas Hood may have found your problem:
> Some devfs permission problems may have arisen because of the
> fact that devfs now notifies devfsd of the creation of
> directories. Many people have devfsd configured to set
> permissions to all devices matching a certain regular
> expression --- e.g., all devices with "sound" in their
> pathname. The problem is that the "sound" directory itself
> matches this regular expression, and so will have its perm
> bits set exactly like the device files' perm bits---e.g.,
> with the eXamine bit cleared. The solution is to edit the
> devfsd config so that it excludes the directory. E.g.,
> instead of:
> REGISTER sound PERMISSIONS root.audio 0664
> (which worked before but won't any more) do:
> REGISTER ^sound/.* PERMISSIONS root.audio 0664
> or something similar.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Hi,
Richard Gooch wrote:
> Well, no, it was never a valid option. It was always a bug. In any
> case, the stricter behaviour isn't preventing people from using their
> drivers, it's just issuing a warning. The user-space created device
> node still works.
But the driver doesn't. You changed the driver API in subtle way! You
cannot change the behaviour of devfs_register during 2.4. Do whatever
you want in 2.5, but drivers depend on the current behaviour and devfs
has to be fixed not these drivers.
bye, Roman
Roman Zippel writes:
> Hi,
>
> Richard Gooch wrote:
>
> > Well, no, it was never a valid option. It was always a bug. In any
> > case, the stricter behaviour isn't preventing people from using their
> > drivers, it's just issuing a warning. The user-space created device
> > node still works.
>
> But the driver doesn't. You changed the driver API in subtle way!
> You cannot change the behaviour of devfs_register during 2.4. Do
> whatever you want in 2.5, but drivers depend on the current
> behaviour and devfs has to be fixed not these drivers.
Tell me how the driver no longer works. I repeat: you now get a
warning. You can still use the driver.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Hi,
Richard Gooch wrote:
> Tell me how the driver no longer works. I repeat: you now get a
> warning. You can still use the driver.
devfs_mk_dir returns an error now, so the driver won't be able to make
new dev nodes available. So far it was legal to manually create a
directory under devfs, now it's suddenly an error.
bye, Roman
Roman Zippel writes:
> Hi,
>
> Richard Gooch wrote:
>
> > Tell me how the driver no longer works. I repeat: you now get a
> > warning. You can still use the driver.
>
> devfs_mk_dir returns an error now, so the driver won't be able to
> make new dev nodes available. So far it was legal to manually create
> a directory under devfs, now it's suddenly an error.
It was always an error, you just got away with it.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Hi,
On Sat, 8 Dec 2001, Richard Gooch wrote:
> > devfs_mk_dir returns an error now, so the driver won't be able to
> > make new dev nodes available. So far it was legal to manually create
> > a directory under devfs, now it's suddenly an error.
>
> It was always an error, you just got away with it.
Sorry, but this is bullshit. You even included an example script with this
"error" (Documentation/filesystems/devfs/rc.devfs). You suddenly change
the behaviour of devfs during a stable release in a noncompatible way.
Distributions and their users that followed _your_ advice are suddenly
fucked up, that's irresponsible. How do you think devfs should be ever
taken seriously?
bye, Roman
Roman Zippel writes:
> Hi,
>
> On Sat, 8 Dec 2001, Richard Gooch wrote:
>
> > > devfs_mk_dir returns an error now, so the driver won't be able to
> > > make new dev nodes available. So far it was legal to manually create
> > > a directory under devfs, now it's suddenly an error.
> >
> > It was always an error, you just got away with it.
>
> Sorry, but this is bullshit. You even included an example script
> with this "error" (Documentation/filesystems/devfs/rc.devfs). You
> suddenly change the behaviour of devfs during a stable release in a
> noncompatible way. Distributions and their users that followed
> _your_ advice are suddenly fucked up, that's irresponsible. How do
> you think devfs should be ever taken seriously?
Oh, the "tar kludge". That script has been obsolete for over a year
and a half. I should have removed it ages ago. I really should get
around to doing that one day.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Richard Gooch wrote:
> Oh, the "tar kludge". That script has been obsolete for over a year
> and a half. I should have removed it ages ago. I really should get
> around to doing that one day.
You should have done this a year ago. Permission management with the
"tar kludge" was a valid option so far and is currently in use. There
was no warning period that this future would be obsolete.
BTW from your devfsd-v1.3.20 release notes:
"NOTE: this release finally provides complete permissions management.
Manually (i.e. non driver or devfsd) created inodes can now be
restored when devfsd starts up. This requires v1.2 of the devfs core
(available in 2.4.17-pre1) for best operation."
The tar solution only works until 2.4.16, the new devfsd provides this
only with 2.4.17. I'll leave the final decision to Marcelo, whether he
accepts this or not. I shut up now, may someone else explain the meaning
of compatibility to you.
bye, Roman
On Sun, 9 Dec 2001, Roman Zippel wrote:
> Richard Gooch wrote:
>
> > Oh, the "tar kludge". That script has been obsolete for over a year
> > and a half. I should have removed it ages ago. I really should get
> > around to doing that one day.
>
> You should have done this a year ago. Permission management with the
> "tar kludge" was a valid option so far and is currently in use. There
> was no warning period that this future would be obsolete.
> BTW from your devfsd-v1.3.20 release notes:
>
> "NOTE: this release finally provides complete permissions management.
> Manually (i.e. non driver or devfsd) created inodes can now be
> restored when devfsd starts up. This requires v1.2 of the devfs core
> (available in 2.4.17-pre1) for best operation."
>
> The tar solution only works until 2.4.16, the new devfsd provides this
> only with 2.4.17. I'll leave the final decision to Marcelo, whether he
> accepts this or not. I shut up now, may someone else explain the meaning
> of compatibility to you.
Roman,
I haven't read the whole thread.
Could you please explain me what is the problem in detail?
Marcelo Tosatti writes:
>
>
> On Sun, 9 Dec 2001, Roman Zippel wrote:
>
> > Richard Gooch wrote:
> >
> > > Oh, the "tar kludge". That script has been obsolete for over a year
> > > and a half. I should have removed it ages ago. I really should get
> > > around to doing that one day.
> >
> > You should have done this a year ago. Permission management with the
> > "tar kludge" was a valid option so far and is currently in use. There
> > was no warning period that this future would be obsolete.
> > BTW from your devfsd-v1.3.20 release notes:
> >
> > "NOTE: this release finally provides complete permissions management.
> > Manually (i.e. non driver or devfsd) created inodes can now be
> > restored when devfsd starts up. This requires v1.2 of the devfs core
> > (available in 2.4.17-pre1) for best operation."
> >
> > The tar solution only works until 2.4.16, the new devfsd provides this
> > only with 2.4.17. I'll leave the final decision to Marcelo, whether he
> > accepts this or not. I shut up now, may someone else explain the meaning
> > of compatibility to you.
>
> Roman,
>
> I haven't read the whole thread.
>
> Could you please explain me what is the problem in detail?
I can explain it. The old devfs core was forgiving of duplicate
entries, while the new one is not (it now gives EEXIST errors).
There are some broken boot scripts (modelled after the long obsolete
rc.devfs script) which dump a whole bunch of inodes in /dev, prior to
loading various modules. So the drivers which load after this will not
be able to create their devfs entries (because said entries already
exist).
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. It is potentially a problem for directories, if the following
conditions are all met:
- boot scripts create a directory in /dev
- driver loads and tries to create same directory (fails)
- driver creates device nodes under that directory using the handle it
obtained from creating the directory
- device nodes driver is trying to create were not created by boot
script (i.e. the untar process).
This is a fairly rare case. Usually, if you are "restoring" some
inodes, you will be restoring the individual device nodes as well as
the parent directory (otherwise, what's the point of restoring?).
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. There
will just be a bunch of warning messages.
Possibly, depending on the driver, the device nodes it tried to create
may appear in the /dev directory, rather than the intended
subdirectory. While perhaps messy, this isn't actually harmful.
This thread was spawned because of a bug report with two issues. The
first issue was the harmless warning messages about duplicate leaf
node entries. Nothing broke.
The second issue was due to a broken devfsd configuration file which
caused the wrong permissions to be set on a directory. This led to
Roman thinking that the new devfs core was breaking stuff. As I've
shown above, the breakage is a rare corner case involving an obsolete
script.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
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.
> 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.
> The second issue was due to a broken devfsd configuration file which
> caused the wrong permissions to be set on a directory. This led to
> Roman thinking that the new devfs core was breaking stuff. As I've
> shown above, the breakage is a rare corner case involving an obsolete
> script.
"rare corner case"??? Richard, this isn't funny anymore. :-(
BTW restoring backward compatibility is probably just a couple of lines
code, but first you had to admit that it's broken.
bye, Roman
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.
>
> > 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 ?
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: [email protected]
Current: [email protected]
On Sun, 9 Dec 2001, Richard Gooch wrote:
> 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.
Please do that.
> I want there to be some pain for broken or really obsolete
> configurations.
Please do that on 2.5: Its already opened.
Thanks
On Sun, 9 Dec 2001, Marcelo Tosatti wrote:
>
>
> On Sun, 9 Dec 2001, Richard Gooch wrote:
>
> > 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.
>
> Please do that.
>
> > I want there to be some pain for broken or really obsolete
> > configurations.
>
> Please do that on 2.5: Its already opened.
Let me rephrase: You can leave the warn message in, but please don't
change behaviour.
At Thu, 6 Dec 2001 23:09:14 -0700,
Richard Gooch wrote:
>
> > Also loading the modules gives me:
> > Dec 7 00:31:58 jackson kernel: devfs: devfs_register(unknown): could not append to parent, err: -17
>
> Two possibilities:
>
> - the module is trying to register "unknown" twice. The old devfs core
> was forgiving about this (although it was always a driver bug to
> attempt to create a duplicate). The new core won't let you do that.
> Error 17 is EEXIST. Please fix the driver
I guess that's a bug (or feature :) in soundcore.
ALSA tries to register the sound devices via register_special(), which
can handle only one card correctly. All devices on 2nd or 3rd cards
are named as "unknown".
The attached patch will fix this problem.
Takashi
* Richard Gooch <[email protected]>:
|> (which worked before but won't any more) do:
|> REGISTER ^sound/.* PERMISSIONS root.audio 0664
|> or something similar.
And what about subdirs, like in case of /dev/ide/...
REGISTER ^ide/.* PERMISSIONS root.disk 0660
sets the permission 0660 on /dev/ide/host0/ also.
On Sat, 22 Dec 2001, Gabor Z. Papp wrote:
> * Richard Gooch <[email protected]>:
> |> (which worked before but won't any more) do:
> |> REGISTER ^sound/.* PERMISSIONS root.audio 0664
> |> or something similar.
>
> And what about subdirs, like in case of /dev/ide/...
> REGISTER ^ide/.* PERMISSIONS root.disk 0660
> sets the permission 0660 on /dev/ide/host0/ also.
If you want to match only /dev/ide then use
REGISTER ^ide$ PERMISSIONS root.disk 0660
--
pozsy
On Sat, 22 Dec 2001, Gabor Z. Papp wrote:
> * Richard Gooch <[email protected]>:
> |> (which worked before but won't any more) do:
> |> REGISTER ^sound/.* PERMISSIONS root.audio 0664
> |> or something similar.
>
> And what about subdirs, like in case of /dev/ide/...
> REGISTER ^ide/.* PERMISSIONS root.disk 0660
> sets the permission 0660 on /dev/ide/host0/ also.
If you want to match only /dev/ide then use
REGISTER ^ide$ PERMISSIONS root.disk 0660
--
pozsy