All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: "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>,
	Grant Likely <grant.likely@secretlab.ca>,
	Alexandre Bounine <alexandre.bounine@idt.com>,
	Stefan Richter <stefanr@s5r6.in-berlin.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	"Ben Dooks \(embedded platforms\)" <ben-linux@fluff.org>,
	"Jean Delvare \(PC drivers, core\)" <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 13:21:07 +0200	[thread overview]
Message-ID: <201106061321.07400.arnd@arndb.de> (raw)
In-Reply-To: <1307352547.7586.6.camel@mulgrave.site>

On Monday 06 June 2011, James Bottomley wrote:
> I'd say it only makes sense if we do it for all busses ... so USB and
> PCI would have to move too.  Logically, the bus code should move and we
> should be left with the drivers in both of those directories.  I'd also
> say that we don't have to deepen the tree: /bus would be fine.  That
> way, /drivers/<bus> would be only for <bus> specific drivers, with non
> bus specific drivers we just group them by function as now.

A top-level /bus would work for me, and I guess would also address Russell's
concern. Regarding bus-specific drivers, we're gradually moving those out
of the bus specific directories anyway, basically the only bus directory
that really has device driver in it is USB at this point. It makes some
sense to have a bus-specific low-level user space interface driver like
sg or uio in the bus directory, but everything else should really belong
into some other subsystem.

> What about the half busses (like SCSI)?

I think SCSI is a really special case, not just because of its size
of more than twice the code than everything else I would suggest to
move, but also because it contains mostly host drivers but very few
device drivers (sd, sr, osst, st, and sg). In that sense it's more
a class of devices than a bus and fits in the same category as
mmc and ata than a bus like pci or i2c that have a multitude of
device drivers.

> Finally, is there any real point (other than we can do it)?  what is
> actually helped by having the bus code obviously separated from the
> driver code (assuming we sort out what is bus and what is driver)?

Mostly I think the drivers/ subdirectory is getting a bit cluttered with
stuff that doesn't really fit together, and bus drivers are typically
directories with less than five files in them, apart from the few
exceptions that already came up.

This is about to get worse as we introduce new subsystems (e.g. iommu,
irq, clocksource, eeprom, nvram, ...) into which we are moving
code from arch/arm, drivers/char and drivers/misc. Having buses and
drivers in a separate hierarchy would make the drivers directory and
the respective menuconfig list more clearly structured IMHO.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Grant Likely <grant.likely@secretlab.ca>,
	Stefan Richter <stefanr@s5r6.in-berlin.de>,
	"Jean Delvare (PC drivers, core)" <khali@linux-fr.org>,
	"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 13:21:07 +0200	[thread overview]
Message-ID: <201106061321.07400.arnd@arndb.de> (raw)
In-Reply-To: <1307352547.7586.6.camel@mulgrave.site>

On Monday 06 June 2011, James Bottomley wrote:
> I'd say it only makes sense if we do it for all busses ... so USB and
> PCI would have to move too.  Logically, the bus code should move and we
> should be left with the drivers in both of those directories.  I'd also
> say that we don't have to deepen the tree: /bus would be fine.  That
> way, /drivers/<bus> would be only for <bus> specific drivers, with non
> bus specific drivers we just group them by function as now.

A top-level /bus would work for me, and I guess would also address Russell's
concern. Regarding bus-specific drivers, we're gradually moving those out
of the bus specific directories anyway, basically the only bus directory
that really has device driver in it is USB at this point. It makes some
sense to have a bus-specific low-level user space interface driver like
sg or uio in the bus directory, but everything else should really belong
into some other subsystem.

> What about the half busses (like SCSI)?

I think SCSI is a really special case, not just because of its size
of more than twice the code than everything else I would suggest to
move, but also because it contains mostly host drivers but very few
device drivers (sd, sr, osst, st, and sg). In that sense it's more
a class of devices than a bus and fits in the same category as
mmc and ata than a bus like pci or i2c that have a multitude of
device drivers.

> Finally, is there any real point (other than we can do it)?  what is
> actually helped by having the bus code obviously separated from the
> driver code (assuming we sort out what is bus and what is driver)?

Mostly I think the drivers/ subdirectory is getting a bit cluttered with
stuff that doesn't really fit together, and bus drivers are typically
directories with less than five files in them, apart from the few
exceptions that already came up.

This is about to get worse as we introduce new subsystems (e.g. iommu,
irq, clocksource, eeprom, nvram, ...) into which we are moving
code from arch/arm, drivers/char and drivers/misc. Having buses and
drivers in a separate hierarchy would make the drivers directory and
the respective menuconfig list more clearly structured IMHO.

	Arnd

  reply	other threads:[~2011-06-06 11:21 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 [this message]
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
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=201106061321.07400.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.