Messages in this thread | | | Date | Sun, 24 Jan 1999 15:49:12 +1100 | From | Richard Gooch <> | Subject | Re: defvs patch v84 for linux 2.2.0-pre9 bugfix |
| |
Heinz Mauelshagen writes: > > The code is more subtle than I first thought. Upon further > > examination, I see that your patch will break mounting devices which > > do not register themselves with register_blkdev() when the > > "devfs=only" boot option is passed. For example, the SCSI disc driver > > calls devfs_register_blkdev() which is a no-op when "devfs=only". > > O.k., have to look deaper into that... > Yes, you are right. > My 2 hours of devfs studies and hacking are not enough 8*)))
Not bad for 2 hours, I reckon.
> > > P.S.: i found another flaw. If someone does chmod a devfs block special > > > sys_chmod/sys_fchmod in linux/fs/open.c updates the dentry but > > > devfs internal cached mode for the inode never changes. > > > If the block special contains a filesystem and you do mount/umount > > > it, your changed permissions are gone afterwards. > > > > This is intentional. Permission changes are > > filesystem-specific. Imagine you have a chroot() gaol and you want to > > change some permissions there but you don't want to affect any other > > mounted devfs'. The current behaviour supports this. > > That's not my problem. > > Different permissions in different mounted devfs _not_ affecting > each other if changes are going on in one of them are o.k. > > > When you unmount a devfs, you lose all the permissions that were > > cached. The current way to fix this is to manaully change the > > permissions when you mount a devfs. > > If i do mount a filesystem using a block device special in one of > the mounted devfs i _don't_ want the permissions be changed by that > mount via the prefiously mentioned devfs_fill_file() scenario. The > permissions should be the same as before the mount.
I don't understand what you're getting at. Your reference to <devfs_fill_file> confuses me more: what does the internals of the mounting process have to do with any permissions? I must be missing the point.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |