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

["Kilau, Scott" <Scott_Kilau@digi.com>]

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