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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 21 Apr 2012 11:09:42 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Wolfram Sang <w.sang@...gutronix.de>
Cc:	Shawn Guo <shawn.guo@...aro.org>,
	Dong Aisheng <aisheng.dong@...escale.com>,
	Huang Shijie <b32955@...escale.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 1/3] lib: add support for stmp-style devices

On Friday 20 April 2012, Wolfram Sang wrote:
> On Fri, Apr 20, 2012 at 01:30:17PM +0800, Shawn Guo wrote:
> > On Wed, Apr 18, 2012 at 11:20:19AM +0200, Wolfram Sang wrote:
> > > > If not, i guess include/linux/fsl which already exists may be the
> > > > right place.
> > > 
> > > Which is a bad choice in my book. linux/dma would have been the proper
> > > thing for mxs-dma.h, I'd think.
> > > 
> > If it already exists, it will be the proper place.  We do not want to
> > be too invasive to create folders in include/linux for every subsystem
> > for only the need of fsl drivers.
> 
> I think linux/dma would have made sense:
> 
> $:~/Kernel/linux/include/linux$ ll *dma*
> -rw-r--r-- 1 ninja ninja  1809 Apr 15 23:32 dma-attrs.h
> ...
> -rw-r--r-- 1 ninja ninja  2631 Apr 15 23:32 sh_dma.h
> -rw-r--r-- 1 ninja ninja   123 Mar 30 22:12 sirfsoc_dma.h
> -rw-r--r-- 1 ninja ninja  1784 Aug 20  2011 timb_dma.h

+1

> > On the other hand, I have seen a clear need for include/linux/fsl.
> > The following files are all good candidates to be moved there.
> > 
> >   include/linux/fsl_devices.h
> 
> I stumbled over this file some time ago. It is an arbitrary collection of stuff
> which should better be seperate. See 'fsl_spi_platform_data'? That should be
> cpm_spi_platform_data. It doesn't even fit to MPC5200 (which SPI driver
> unnecessarily includes this file), let alone i.MX, so calling it 'fsl' doesn't
> make sense at all. I fear similar confusion with a fsl-directory.

Agreed. I would much prefer to avoid any such vendor specific silos for where to
dump random code. A file for a company that makes both powerpc and arm SoCs
that have a few components in common but also share other components with other
SoCs of the respective architectures does not seem very useful to me.

> >   include/linux/fsl-diu-fb.h
> 
> Sadly, another bad choice. It should have gone to include/video like all other
> fb-drivers.
> 
> >   include/linux/fsl_hypervisor.h
> 
> And that could simply stay in include/linux then, like kvm does.

Well, we could also have a linux/virt/ directory. Unfortunately in both these
cases we have no choice any more because they contain ioctl data structures
that are exported to user space, so we cannot move these files without
breaking user space programs and we don't do that.

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ