From: Arnd Bergmann <arnd@arndb.de>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Grant Likely <grant.likely@secretlab.ca>,
"Maciej W. Rozycki" <macro@linux-mips.org>,
Rusty Russell <rusty@rustcorp.com.au>,
Russell King <linux@arm.linux.org.uk>,
Michael Buesch <mb@bu3sch.de>,
linux-pcmcia@lists.infradead.org, linux-kernel@vger.kernel.org,
Florian Fainelli <florian@openwrt.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Alexandre Bounine <alexandre.bounine@idt.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
"Ben Dooks \(embedded platforms\)" <ben-linux@fluff.org>,
Jean Delvare <khali@linux-fr.org>,
spi-devel-general@lists.sourceforge.net,
Matt Porter <mporter@kernel.crashing.org>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] spi: reorganize drivers
Date: Mon, 6 Jun 2011 17:04:27 +0200 [thread overview]
Message-ID: <201106061704.27196.arnd@arndb.de> (raw)
In-Reply-To: <20110606154447.51f07c7b@stein>
On Monday 06 June 2011, Stefan Richter wrote:
> On Jun 06 Arnd Bergmann wrote:
> > On Monday 06 June 2011, Jean Delvare wrote:
> On drivers/firewire/:
>
> FireWire drivers are currently spread over drivers/firewire (three
> link-layer controller drivers + the IEEE 1394 core + two IEEE 1394
> application layer drivers), drivers/media/dvb/firewire/ (one 1394
> application layer driver), sound/firewire/ (two 1394 application layer
> drivers, more are planned to be added there).
>
> From the Linux driver model POV,
> 1. the IEEE 1394 core driver implements the firewire bus,
> 2. the link-layer controller drivers implement pci bus based devices,
> 3. the IEEE 1394 application layer drivers implement firewire bus based
> devices. The two of them that are located in drivers/firewire/
> expose a SCSI LLD (a transport in SCSI Architecture Model terms, but
> a host rather than a transport in Linux implementation terms) and a
> networking interface driver.
>
> Number 2 is something one would expect to find in a hypothetical
> drivers/bus/ directory. But where do the others belong?
>
> Would type 1 drivers be kept in drivers/bus/firewire/? I understand your
> above response to Jean that this is what you have in mind.
Correct.
> firewire-sbp2 could be moved into drivers/scsi/, and firewire-net could be
> moved into drivers/net/. But what about maintenance? They could still be
> maintained via linux1394-2.6.git because this worked so far, but then the
> directory structure might irritate people who don't use
> scripts/get_maintainer.pl all the time. Well, I could actually picture
> firewire-net to be maintained via the net development tree, but I do
> wonder how well firewire-sbp2 maintenance through the scsi tree would work.
I guess the real question is whether firewire should be considered a bus
like USB or a device class like SCSI, and it's abit of a grey area (SCSI
is too). If you declare it to be a bus, I'd suggest moving the sbp2 and
network drivers to drivers/scsi and drivers/net. If you like to think
of firewire as a closed subsystem instead, it's probably better to leave
all of it in drivers/firewire.
> PS,
> these are the same questions like with USB, only on a smaller scale. (The
> usb-storage driver is maintained through the usb tree as well, not the
> scsi tree. drivers/net/usb/ has got T: git .../gregkh/usb-2.6.git
> assigned in MAINTAINERS but most of the commits there are actually done by
> DaveM.)
The difference that I see with usb-storage is that this one is really
a set of different drivers for all sorts of devices, while the firewire sbp2
driver feels more like a single driver that includes a few special
cases. Also, USB is generally perceived as a generic interconnect, while
firewire is seen primarily as a way to attach disk drives.
The differences are of course gradual.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Jean Delvare <khali@linux-fr.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Grant Likely <grant.likely@secretlab.ca>,
"Ben Dooks (embedded platforms)" <ben-linux@fluff.org>,
linux-pcmcia@lists.infradead.org,
Matt Porter <mporter@kernel.crashing.org>,
Alexandre Bounine <alexandre.bounine@idt.com>,
"David S. Miller" <davem@davemloft.net>,
Michael Buesch <mb@bu3sch.de>,
"Maciej W. Rozycki" <macro@linux-mips.org>,
Rusty Russell <rusty@rustcorp.com.au>,
Florian Fainelli <florian@openwrt.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
spi-devel-general@lists.sourceforge.net,
linux-kernel@vger.kernel.org,
Russell King <linux@arm.linux.org.uk>
Subject: Re: [PATCH] spi: reorganize drivers
Date: Mon, 6 Jun 2011 17:04:27 +0200 [thread overview]
Message-ID: <201106061704.27196.arnd@arndb.de> (raw)
In-Reply-To: <20110606154447.51f07c7b@stein>
On Monday 06 June 2011, Stefan Richter wrote:
> On Jun 06 Arnd Bergmann wrote:
> > On Monday 06 June 2011, Jean Delvare wrote:
> On drivers/firewire/:
>
> FireWire drivers are currently spread over drivers/firewire (three
> link-layer controller drivers + the IEEE 1394 core + two IEEE 1394
> application layer drivers), drivers/media/dvb/firewire/ (one 1394
> application layer driver), sound/firewire/ (two 1394 application layer
> drivers, more are planned to be added there).
>
> From the Linux driver model POV,
> 1. the IEEE 1394 core driver implements the firewire bus,
> 2. the link-layer controller drivers implement pci bus based devices,
> 3. the IEEE 1394 application layer drivers implement firewire bus based
> devices. The two of them that are located in drivers/firewire/
> expose a SCSI LLD (a transport in SCSI Architecture Model terms, but
> a host rather than a transport in Linux implementation terms) and a
> networking interface driver.
>
> Number 2 is something one would expect to find in a hypothetical
> drivers/bus/ directory. But where do the others belong?
>
> Would type 1 drivers be kept in drivers/bus/firewire/? I understand your
> above response to Jean that this is what you have in mind.
Correct.
> firewire-sbp2 could be moved into drivers/scsi/, and firewire-net could be
> moved into drivers/net/. But what about maintenance? They could still be
> maintained via linux1394-2.6.git because this worked so far, but then the
> directory structure might irritate people who don't use
> scripts/get_maintainer.pl all the time. Well, I could actually picture
> firewire-net to be maintained via the net development tree, but I do
> wonder how well firewire-sbp2 maintenance through the scsi tree would work.
I guess the real question is whether firewire should be considered a bus
like USB or a device class like SCSI, and it's abit of a grey area (SCSI
is too). If you declare it to be a bus, I'd suggest moving the sbp2 and
network drivers to drivers/scsi and drivers/net. If you like to think
of firewire as a closed subsystem instead, it's probably better to leave
all of it in drivers/firewire.
> PS,
> these are the same questions like with USB, only on a smaller scale. (The
> usb-storage driver is maintained through the usb tree as well, not the
> scsi tree. drivers/net/usb/ has got T: git .../gregkh/usb-2.6.git
> assigned in MAINTAINERS but most of the commits there are actually done by
> DaveM.)
The difference that I see with usb-storage is that this one is really
a set of different drivers for all sorts of devices, while the firewire sbp2
driver feels more like a single driver that includes a few special
cases. Also, USB is generally perceived as a generic interconnect, while
firewire is seen primarily as a way to attach disk drives.
The differences are of course gradual.
Arnd
next prev parent reply other threads:[~2011-06-06 15:04 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-05 7:18 [PATCH] spi: reorganize drivers Grant Likely
2011-06-05 7:43 ` Jassi Brar
[not found] ` <BANLkTinoEQf2a65KwQZOVK_4H9DSfqybjA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-05 7:54 ` Baruch Siach
2011-06-05 7:54 ` Baruch Siach
2011-06-05 11:49 ` Geert Uytterhoeven
2011-06-05 13:08 ` Stefan Richter
2011-06-05 20:55 ` Grant Likely
2011-06-05 21:19 ` Jassi Brar
2011-06-05 13:12 ` Jassi Brar
2011-06-05 20:57 ` Grant Likely
2011-06-05 8:13 ` Mika Westerberg
2011-06-05 14:37 ` Grant Likely
2011-06-06 9:00 ` Arnd Bergmann
2011-06-06 9:00 ` Arnd Bergmann
2011-06-06 9:08 ` Dominik Brodowski
2011-06-06 9:08 ` Russell King - ARM Linux
2011-06-06 9:08 ` Russell King - ARM Linux
2011-06-06 9:17 ` Jean Delvare
2011-06-06 9:29 ` James Bottomley
2011-06-06 11:21 ` Arnd Bergmann
2011-06-06 11:21 ` Arnd Bergmann
2011-06-06 12:16 ` Jean Delvare
2011-06-06 12:16 ` Jean Delvare
2011-06-06 12:35 ` Geert Uytterhoeven
2011-06-06 12:35 ` Geert Uytterhoeven
[not found] ` <20110606141636.150c54b5-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2011-06-06 12:57 ` Arnd Bergmann
2011-06-06 12:57 ` Arnd Bergmann
2011-06-06 13:44 ` Stefan Richter
2011-06-06 13:44 ` Stefan Richter
2011-06-06 15:04 ` Arnd Bergmann [this message]
2011-06-06 15:04 ` Arnd Bergmann
2011-06-06 10:01 ` Geert Uytterhoeven
2011-06-06 10:01 ` Geert Uytterhoeven
2011-06-06 14:39 ` Grant Likely
2011-06-06 14:39 ` Grant Likely
2011-06-06 15:15 ` Russell King - ARM Linux
2011-06-06 15:15 ` Russell King - ARM Linux
-- strict thread matches above, loose matches on Subject: below --
2011-06-05 7:13 Grant Likely
2011-06-07 9:28 ` Linus Walleij
2011-06-07 13:26 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201106061704.27196.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=James.Bottomley@hansenpartnership.com \
--cc=alexandre.bounine@idt.com \
--cc=ben-linux@fluff.org \
--cc=davem@davemloft.net \
--cc=florian@openwrt.org \
--cc=geert@linux-m68k.org \
--cc=grant.likely@secretlab.ca \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pcmcia@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=macro@linux-mips.org \
--cc=mb@bu3sch.de \
--cc=mporter@kernel.crashing.org \
--cc=rusty@rustcorp.com.au \
--cc=spi-devel-general@lists.sourceforge.net \
--cc=stefanr@s5r6.in-berlin.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.