EXPORT_SYMBOL for chrdev_open 2.4.3
It would be nice if chrdev_open were added to ksyms.c along with blkdev_open since tape devices seem are always registered as character rather than block devices.
I am finding that kernel modules that need to open and close a tape drive have to export chrdev_open manually on 2.4.3. Can this get exported as well? Closing is not a problem since the method of calling (->release) seems to work OK with SCSI tape devices.
:-)
Jeff
Quoted 8 lines · Jeff V. Merkey
It would be nice if
chrdev_openwere added toksyms.calong withblkdev_opensince tape devices seem are always registered as character rather than block devices.I am finding that kernel modules that need to open and close a tape drive have to export
chrdev_openmanually on 2.4.3. Can this get exported as well? Closing is not a problem since the method of calling (->release) seems to work OK with SCSI tape devices.
They don't need it. Moreover, blkdev_open shouldn't be exported too - the only potentially modular piece of code that refers to it is drivers/block/rd.c and it's in initrd loading, so it isn't even compiled when we do rd as a module.
BTW, Linus, could we remove blkdev_open() from the export list? I don't see any legitimate reason to export it - certainly not in the official tree.
BTW, fs/partitions/ibm.c also doesn't need blkdev_open() - it should use ioctl_by_bdev() and be done with that.
Al
Quoted 18 lines · Alexander Viro
Quoted 8 lines · Jeff V. Merkey
It would be nice if
chrdev_openwere added toksyms.calong withblkdev_opensince tape devices seem are always registered as character rather than block devices.I am finding that kernel modules that need to open and close a tape drive have to export
chrdev_openmanually on 2.4.3. Can this get exported as well? Closing is not a problem since the method of calling (->release) seems to work OK with SCSI tape devices.They don't need it. Moreover,
blkdev_openshouldn't be exported too - the only potentially modular piece of code that refers to it isdrivers/block/rd.cand it's in initrd loading, so it isn't even compiled when we do rd as a module.
Quoted 6 lines
BTW, Linus, could we remove
blkdev_open()from the export list? I don't see any legitimate reason to export it - certainly not in the official tree.BTW,
fs/partitions/ibm.calso doesn't needblkdev_open()- it should useioctl_by_bdev()and be done with that.
Al,
How are folks supposed to open disk and tape devices from kernel modules without these? Not everything should be done in user space Al. If you remove blkdev_open I will not be able to properly increment the use count an a disk device I may be reading or writing to.
Jeff
Quoted 1 line
Al
Quoted 2 lines · Jeff V. Merkey
How are folks supposed to open disk and tape devices from kernel modules without these? Not everything should be done in user space Al. If you
Normally - filp_open(). If all you want is ioctl on block device - blkdev_get() + ioctl_by_bdev() + blkdev_put(). If you want it by device _number_ - use bdget().
Quoted 2 lines
remove
blkdev_openI will not be able to properly increment the use count an a disk device I may be reading or writing to.
Yes, you will. And I would _really_ advice you to do that by
name instead of device number - that way you will avoid a lot of pain couple of years down the road.
Quoted 10 lines · Alexander Viro
Quoted 2 lines · Jeff V. Merkey
How are folks supposed to open disk and tape devices from kernel modules without these? Not everything should be done in user space Al. If you
Normally -
filp_open(). If all you want is ioctl on block device -blkdev_get()+ioctl_by_bdev()+blkdev_put(). If you want it by device _number_ - usebdget().
Quoted 8 lines
Quoted 2 lines
remove
blkdev_openI will not be able to properly increment the use count an a disk device I may be reading or writing to.Yes, you will. And I would _really_ advice you to do that by
name instead of device number - that way you will avoid a lot of pain couple of years down the road.
This is **VERY** good to know, and also shows that you in fact have looked through my code.
:-)
Jeff
Quoted 9 lines · Jeff V. Merkey
Quoted 8 lines · Alexander Viro
Quoted 4 lines · Jeff V. Merkey
It would be nice if
chrdev_openwere added toksyms.calong withblkdev_opensince tape devices seem are always registered as character rather than block devices.
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
I am finding that kernel modules that need to open and close a tape drive have to export
chrdev_openmanually on 2.4.3. Can this get exported as well? Closing is not a problem since the method of calling (->release) seems to work OK with SCSI tape devices.They don't need it.
Al,
Not meaning to offend, but how could you know what everyone who uses Linux needs in every instance? NT, NetWare, etc. all expose these types of APIs for Backup and anti-virus software, etc. The APIs in question are the very calls user space apps call through the syscall to indicate who is using a device.
Sure, I can send blind I/O requests to a device and I guess someone running fdisk in user space can blow the device away from beneath me since I have no way of locking those partitions I exclusively own and stopping this is these apis are removed and modules cannot call them.
Jeff
Quoted 29 lines
Quoted 11 lines
Moreover,
blkdev_openshouldn't be exported too -
the only potentially modular piece of code that refers to it isdrivers/block/rd.cand it's in initrd loading, so it isn't even compiled when we do rd as a module.BTW, Linus, could we remove
blkdev_open()from the export list? I don't see any legitimate reason to export it - certainly not in the official tree.BTW,
fs/partitions/ibm.calso doesn't needblkdev_open()- it should useioctl_by_bdev()and be done with that.Al,
How are folks supposed to open disk and tape devices from kernel modules without these? Not everything should be done in user space Al. If you remove
blkdev_openI will not be able to properly increment the use count an a disk device I may be reading or writing to.Jeff
Quoted 1 line
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · Jeff V. Merkey
Not meaning to offend, but how could you know what everyone who uses Linux needs in every instance? NT, NetWare, etc. all expose these types of APIs for Backup and anti-virus software, etc. The APIs in question are the very calls user space apps call through the syscall to indicate who is using a device.
Backup and AV software is not in the kernel, so they would be unable to use the thing, exported or not. Please, don't bring the strawmen.
Novell's model (aka. "we don't need no stinkin' userland, everything is NLM and security be damned") is better left to rot in hell with Novell.
Quoted 5 lines
Sure, I can send blind I/O requests to a device and I guess someone running fdisk in user space can blow the device away from beneath me since I have no way of locking those partitions I exclusively own and stopping this is these apis are removed and modules cannot call them.
Use filp_open() - it's that simple.
Quoted 10 lines · Alexander Viro
Quoted 5 lines · Jeff V. Merkey
Not meaning to offend, but how could you know what everyone who uses Linux needs in every instance? NT, NetWare, etc. all expose these types of APIs for Backup and anti-virus software, etc. The APIs in question are the very calls user space apps call through the syscall to indicate who is using a device.
Quoted 3 lines
Backup and AV software is not in the kernel, so they would be unable to use the thing, exported or not. Please, don't bring the strawmen.
Some NT anti-virus stuff is in-kernel, and it's there to catch people writing viruses that act like device drivers. One day, if and when a Linux virus shows it's ugly head disguised as a kernel module, you will be backpeddling on this statement, and wishing we had in kernel anti-virus support. In W2K, folks have written some clever viruses that plug into their kernel as bogus device drivers.
Quoted 3 lines
Novell's model (aka. "we don't need no stinkin' userland, everything is NLM and security be damned") is better left to rot in hell with Novell.
Well, I am working with them again, and they have taken quite a beating at our hands (and I sure didn't do them any good putting out the file system on Linux and free Migration tools). Saying the word "Linux" around Novell definitely solicits a very worried and serious response.
I am trying to be nice to them -- Linux is eroding their installed base at light speed at this point. I'm sorry to say they show absolutely **NO** interest in doing things to promote Linux to their installed base in anyway that could benefit either them or Linux.
Quoted 8 lines
Quoted 6 lines
Sure, I can send blind I/O requests to a device and I guess someone running fdisk in user space can blow the device away from beneath me since I have no way of locking those partitions I exclusively own and stopping this is these apis are removed and modules cannot call them.
Use
filp_open()- it's that simple.
Thanks. This is what I needed to know. I saw filp_open() in the EXPORTS file, but was uncertain if this would be an unchanging API. You have clarified this.
I will convert my code to use this call instead. Linus, if Al wants the APIs removed from the export list, it sounds like filp_open() will handle future issues relative to my requirements, so I have no objection to them being removed.
I'll let Al know if there are any problems with using them.
Al, Thanks for the info.
:-)
Jeff
Quoted 6 lines · Jeff V. Merkey
Quoted 3 lines
Backup and AV software is not in the kernel, so they would be unable to use the thing, exported or not. Please, don't bring the strawmen.
Some NT anti-virus stuff is in-kernel, and it's there to catch people writing viruses that act like device drivers. One day, if and
<shrug> If attacker can trick kernel into loading _any_ untrusted code, no matter what contents it got, in ring 0 - you've lost anyway.
Quoted 2 lines
when a Linux virus shows it's ugly head disguised as a kernel module, you will be backpeddling on this statement, and wishing we had in
No, I will be busy fixing the hole that allows to get untrusted code loaded. I don't give a fsck whether it's a virus or not - if admin authorized it it's his responsibility, if not - ability to get it into the kernel space is a gaping hole that should be closed.
Quoted 4 lines
Quoted 1 line
Use
filp_open()- it's that simple.Thanks. This is what I needed to know. I saw
filp_open()in the EXPORTS file, but was uncertain if this would be an unchanging API.
Yes, it is. It's a kernel counterpart of open() - the only difference is that instead of installing a reference to file into descriptor table and returning the descriptor it returns the reference itself. Arguments are the same as in case of open() and it's certainly there to stay.
Al