> > 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 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/
-
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/