linux-kernel - Re: [PATCH] spi: reorganize drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 6 Jun 2011 13:21:07 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	James Bottomley <James.Bottomley@...senpartnership.com>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	"Jean Delvare (PC drivers, core)" <khali@...ux-fr.org>,
	"Ben Dooks (embedded platforms)" <ben-linux@...ff.org>,
	linux-pcmcia@...ts.infradead.org,
	Matt Porter <mporter@...nel.crashing.org>,
	Alexandre Bounine <alexandre.bounine@....com>,
	"David S. Miller" <davem@...emloft.net>,
	Michael Buesch <mb@...sch.de>,
	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Florian Fainelli <florian@...nwrt.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	spi-devel-general@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, Russell King <linux@....linux.org.uk>
Subject: Re: [PATCH] spi: reorganize drivers

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/