Linus & Marcelo,
For SGI's upcoming Linux platform (nicknamed Scalable Node, or SN),
we have some platform specific device drivers. Where should these go?
I see several precedents in the current kernels.
1) Integrate in drivers/*.
Integrate SN drivers into appropriate directories.
Put them directly in char, net, misc, etc., as appropriate.
2) Company (sgi) directory.
There is already an sgi directory, strangely enough.
I *think* this was meant to be a platform directory for the
discontinued SGI 320/540 Visual Workstations. However, maybe
it was intended to be a new precedent of company specific
directories. In this case, we'd probably create a platform
directory under the company directory, so there would likely
be drivers/sgi/sn (some of our SN drivers are here today in
our internal development tree). However, there is no other
precedent for "company" subdirectories under drivers. Apple
didn't do it. IBM didn't do it. HP hasn't done it. Was the
drivers/sgi directory really intended to start a new
precedent of company specific directories under drivers?
3) New platform directory.
Create a platform directory for SN, probably drivers/sn.
There is precedence for this with the drivers/macintosh
and drivers/s390. Also, as noted, the SGI Visual Workstation
drivers are in drivers/sgi. In this case, it might also make
sense to rename drivers/sgi to drivers/visws to indicate
these are drivers for the Visual Workstation platform, and
not generic SGI drivers.
4) New architecture directory.
Another suggestion is to create an architecture directory,
in this case drivers/ia64/{char,net,etc.}/.
I'm happy with whatever you'll accept. To give you something to
either agree with or shoot down, I'll suggest #3. SGI's Scalable
Node product will be different enough, with enough platform specific
drivers, that it justifies it's own subdirectory, and that this
should be called drivers/sn.
John Hesterberg
[email protected]
On Mon, Feb 11, 2002 at 01:17:44PM -0600, John Hesterberg wrote:
> 3) New platform directory.
> Create a platform directory for SN, probably drivers/sn.
> There is precedence for this with the drivers/macintosh
Being a PPC person, I sometimes wonder if this wsn't a horrible idea
sometimes. Much of whats in thereshould be in a 'drivers/adb' or so,
ince it's all specific to the ADB bus, with the exception of things like
'rtc.c' (which works on all PPC except APUS). Keep in mind other
'macintosh' specific drivers, like network ones, are in drivers/net/.
Wer also have an arch/ppc/{8xx,8260}_io/ directories for other
platform-specific drivers, which I want to kill in 2.5.x timeframe.
> I'm happy with whatever you'll accept. To give you something to
> either agree with or shoot down, I'll suggest #3. SGI's Scalable
> Node product will be different enough, with enough platform specific
> drivers, that it justifies it's own subdirectory, and that this
> should be called drivers/sn.
What excelty are the specific to tho? Are these all for a new bus?
If these are just variopus network, io, whatnot drivers, just put them
in drivers/whatever.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
> For SGI's upcoming Linux platform (nicknamed Scalable Node, or SN),
> we have some platform specific device drivers. Where should these go?
> 1) Integrate in drivers/*.
I'd do this, unless you have dozens of them.
E.g. drivers/net/sunhme.c.
> 2) Company (sgi) directory.
That's nonsense, IMHO.
> 3) New platform directory.
> Create a platform directory for SN, probably drivers/sn.
> There is precedence for this with the drivers/macintosh
> and drivers/s390.
I think this is only done if API is different. Often these
directories cannot be processed by a build process on other
architectures, so they are kept outside to have Makefiles smaller.
See also drivers/sbus, which could be called "drivers/sun" just
as well. But really, it's separate because of sparc_alloc_io().
I appreciate a lot that drivers/acpi is so easy to exclude
from builds - it breaks on anything but Intel stuff.
> 4) New architecture directory.
> Another suggestion is to create an architecture directory,
> in this case drivers/ia64/{char,net,etc.}/.
See #3. The ia64 uses standard APIs.
> I'm happy with whatever you'll accept.
Yeah, lessee what penguins say, and also I think DaveM may
lend some good expirience here.
-- Pete
On Mon, Feb 11, 2002 at 01:17:44PM -0600, John Hesterberg wrote:
>
> For SGI's upcoming Linux platform (nicknamed Scalable Node, or SN),
> we have some platform specific device drivers. Where should these go?
> I see several precedents in the current kernels.
>
> [...]
>
> 2) Company (sgi) directory.
> There is already an sgi directory, strangely enough.
> I *think* this was meant to be a platform directory for the
> discontinued SGI 320/540 Visual Workstations. However, maybe
You are mistaken. The cruft in drivers/sgi mostly dates back to the
attempts on the SGI Indy platform to get SGI's IRIX X server *binary*
running under Linux (note that this work was NOT done by SGI).
The SGI Visual Workstation work was mostly done within the i386 arch
code; the framebuffer driver (sgivwfb.[ch]) was put in drivers/video;
and some other drivers had some modifications that were guarded
by CONFIG_VISWS or CONFIG_VISWS_HACKS. (There was also a project that
enabled multi-process accelerated/direct-rendered graphics on that
platform, but that code was never released due to the fact that the
project was killed the week it was demonstrated at SIGGRAPH'99.)
--macko
On Mon, 11 Feb 2002, John Hesterberg wrote:
>
> For SGI's upcoming Linux platform (nicknamed Scalable Node, or SN),
> we have some platform specific device drivers. Where should these go?
> I see several precedents in the current kernels.
If they are equivalent to a new bus, make a new platform directory under
drivers, is my vote.
However, if they are likely to eventually spread out (ie they are
really PCI-based, and just your own private chips, and they might end up
as part of some other sgi platform), spread them out as normal drivers.
Linus