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
On Fri, 13 Apr 2001, Jeff V. Merkey wrote:
> 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.
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
On Fri, Apr 13, 2001 at 08:13:41PM -0400, Alexander Viro wrote:
>
>
> On Fri, 13 Apr 2001, Jeff V. Merkey wrote:
>
> > 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.
>
> 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,
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
> Al
On Fri, Apr 13, 2001 at 06:38:10PM -0600, Jeff V. Merkey wrote:
> On Fri, Apr 13, 2001 at 08:13:41PM -0400, Alexander Viro wrote:
> >
> >
> > On Fri, 13 Apr 2001, Jeff V. Merkey wrote:
> >
> > > 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.
> >
> > 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
> > 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,
>
> 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
>
>
> > 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/
On Fri, 13 Apr 2001, Jeff V. Merkey wrote:
> 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().
> 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.
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.
On Fri, 13 Apr 2001, Jeff V. Merkey wrote:
> 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.
> 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.
On Fri, Apr 13, 2001 at 09:29:43PM -0400, Alexander Viro wrote:
>
> On Fri, 13 Apr 2001, Jeff V. Merkey wrote:
>
> > 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().
>
> > 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.
>
> 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
On Fri, Apr 13, 2001 at 09:25:10PM -0400, Alexander Viro wrote:
>
>
> On Fri, 13 Apr 2001, Jeff V. Merkey wrote:
>
> > 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.
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.
>
> 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.
>
> > 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
On Fri, 13 Apr 2001, Jeff V. Merkey wrote:
> > 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.
> 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.
> > 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