RE: Digi Neo 8: linux-2.6.12_r2 jsm driver

From: Kilau, Scott (Scott_Kilau_at_digi.com)
Date: 04/12/05

  • Next message: Chris Wright: "Re: [stable] [patch 1/1] uml: add nfsd syscall when nfsd is modular"
    Date:	Tue, 12 Apr 2005 15:01:32 -0500
    To: "Jan-Benedict Glaw" <jbglaw@lug-owl.de>
    
    

    > There's a consensus that if there's *any* choice, new /proc files as
    > well as new ioctls shall not be introduced. So if there's management needed

    Oh, keep in mind, the ioctls are not new.

    They exist today, and are clearly defined in Documentation/ioctl-number.txt
    > 'd' F0-FF linux/digi1.h

    But we have already been down this road in a previous thread,
    and I gave up on that argument as well. =)

    Scott Kilau

    -----Original Message-----
    From: Jan-Benedict Glaw [mailto:jbglaw@lug-owl.de]
    Sent: Tuesday, April 12, 2005 1:49 PM
    To: Kilau, Scott
    Cc: Christoph Hellwig; Ihalainen Nickolay; admin@list.net.ru; linux-kernel@vger.kernel.org; Wen Xiong
    Subject: Re: Digi Neo 8: linux-2.6.12_r2 jsm driver

    On Tue, 2005-04-12 11:42:31 -0500, Kilau, Scott <Scott_Kilau@digi.com>
    wrote in message <335DD0B75189FB428E5C32680089FB9F12215A@mtk-sms-mail01.digi.com>:
    > The JSM driver was forced to be stripped down when being submitted
    > to the kernel sources, and many extended features removed as so to be
    > included into the kernel, as the extended features added special ioctls
    > and special /proc (/sys for 2.6) files.

    There's a consensus that if there's *any* choice, new /proc files as
    well as new ioctls shall not be introduced. So if there's management
    needed (disclaimer: I don't own such a card), then this interface needs
    to be introduced as a generic interface, which might be used by any
    further drivers. We've just had this situation for some RAID cards,
    where the vendor wanted to introduce a (specific for his devices)
    interface. Either do it correct (as of best current practice), or don't
    do it at all.

    > > I didn't think that you would remove them. I read the posts and
    > > wondered *why* they wanted the management pieces removed.
    > > One reason to use the Digi products is for the sole fact that
    > > they *can* be diagnosed.
    > > I'm glad that Digi is still focused properly.
    > > I agree that committing the drivers to the main kernel
    > > is not the way to go if you are forced to remove dpa and ditty.

    Well, again, if this features can only used by your hardware (and
    there's proof that no other vendor will add these features *ever*), then
    an own interface is okay. But if there's a possibility that a different
    vendor *might* introduce these as well, then a generic interface needs
    to be build (with first of all only one user: your driver).

    > I will let the chips fall where they will, and clean up the mess that
    > will soon be introduced into my driver world. =)

    That's a plan. Good to head :-)

    MfG, JBG

    -- 
    Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
    "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
     fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
    ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
    -
    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/
    

  • Next message: Chris Wright: "Re: [stable] [patch 1/1] uml: add nfsd syscall when nfsd is modular"

    Relevant Pages

    • Re: ioctl number 0xF3
      ... > The interface I intend to use matches the one the X driver has (using ... > the Xv extension as an ioctl replacement) and will be documented. ... > I develope both the SiS kernel framebuffer driver as well as the SiS X ... use as few ioctls as possible so that you can control/verify the changes ...
      (Linux-Kernel)
    • Re: ioctl number 0xF3
      ... I didn't mean that as any sort of insult. ... people telling me "implement a generic interface". ... driver and want the users of this driver to have some sort of comfort. ... intended ioctls already implemented. ...
      (Linux-Kernel)
    • Re: Digi Neo 8: linux-2.6.12_r2 jsm driver
      ... > included into the kernel, as the extended features added special ioctls ... , then this interface needs ... to be build (with first of all only one user: your driver). ...
      (Linux-Kernel)
    • Re: ioctls, etc. (was Re: [PATCH 1/4] sas: add flag for locally attached PHYs)
      ... > ioctls represent the most direct, ... > potentially a few levels down a driver stack. ... sysfs, since its normal ASCII ... This entirely depends on the interface you define. ...
      (Linux-Kernel)
    • RE: [ANNOUNCE] QLogic qla2xxx driver update available (v8.00.00b7).
      ... > I didn't see any comments about Christoph's patches, so is it OK if I ... the driver now, ... IOCTLs were mainly used and built upon due the platform agnostic ... use the platform's IOCTL interface with the QLogic ...
      (Linux-Kernel)