[lkml]   [2001]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFD w/info-PATCH] device arguments from lookup, partion code
    Date said:
    > Now, a good way to force the issue may be to just remove the "ioctl"
    > function pointer from the file operations structure altogether. We
    > don't have to force peopel to use "read/write" - we can just make it
    > clear that ioctl's _have_ to be wrapped, and that the only ioctl's
    > that are acceptable are the ones that are well-designed enough to be
    > wrappable. So we'd have a "linux/fs/ioctl.c" that would do all the
    > wrapping,

    I have so far resisted adding an 'ioctl' method to the MTD structure. Yet
    because userspace needs to be able to request an erase, request information
    about the erasesize of the device, etc., I've got an ioctl wrapper much as
    you describe in drivers/mtd/mtdchar.c. It calls _real_ functions like
    ->erase() in the underlying MTD device, which can't easily be exposed to
    userspace (unless we do something silly like using CORBA :)

    I can see the advantage of doing what you suggest - add methods to the
    struct block_device for the sensible things like HDIO_GETGEO, BLKGETSIZE,
    etc. (and anyone suggesting that it's sensible to have the physical block
    device driver at all involved in BLKRRPART shall be summarily shot).

    But please don't _actually_ put all the ioctl wrappers in fs/ioctl.c. It'd
    be a nightmare for the maintainers of the various sections of it.

    Besides, what on earth does it have to do with file systems?

    Maybe abi/ioctl/{blkdev,mtd,usb,scsi,...}.c ?

    Having it outside the directories which are traditionally owned by the
    respective subsystem maintainers means that it's far easier to be fascist
    about what's added, too.

    On a related note - I was actually beginning to consider a dev-private ioctl
    for MTD devices, actually for reasons of taste - some stuff like turning
    on/off the automatic hardware ECC on the DiskOnChip devices I consider ugly
    enough that I didn't want to deal with it in generic code. At least a
    dev-private ioctl seemed like it would banish the ugliness into the
    offending driver, and be vaguely reusable if any other device turned out to
    require such ugliness.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:53    [W:0.021 / U:14.984 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site