linux-kernel - Re: [PATCH 0/7] staging: lustre: last missing patches for lustre 2.6

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:   Mon, 22 Aug 2016 10:55:42 -0700
From:   Joe Perches <joe@...ches.com>
To:     James Simmons <jsimmons@...radead.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        devel@...verdev.osuosl.org,
        Andreas Dilger <andreas.dilger@...el.com>,
        Oleg Drokin <oleg.drokin@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Lustre Development List <lustre-devel@...ts.lustre.org>
Subject: Re: [PATCH 0/7] staging: lustre: last missing patches for lustre 2.6

On Mon, 2016-08-22 at 18:41 +0100, James Simmons wrote:
> On Fri, 2016-08-19 at 20:44 +0100, James Simmons wrote:

Hi again James.

> > I don't _need_ anything, but I think it'd be simpler to
> > have just 2 directories, one for lustre kernel stuff
> > and another for lustre uapi stuff.
> > 
> > That applies for LNet and libcfs #includes as well.
> > 
> > To me, ideally, there'd only be 2 #include directories
> > so that the only used #include styles could become:
> > 
> > #include 
> > and
> > #include 
> > 
> > and that would work regardless of lustre's layout
> > in staging or elsewhere.
> I didn't expect this to be requested at this time. I thought this would be 
> addressed just before we left staging.

Sooner is better to me, but that's up to you all.

> I had to ponder the impact of
> this change since this affects our userland utilities as well. Moving
> the staging/lustre/lustre/include/* to include/linux/lustre is pretty
> straight forward for the internal kernel headers.
> 
> The issues is that we still have entanglement issues with some of our uapi 
> headers with internals of the kernel leaking to userland.

Identifying the u_int_<size> and __u<size> types in the code
by userland/kernel uses could be done more easily after any
#include uapi/kernel separation is done.
> Would that be acceptable?

That's not for me to decide really.
It's not an immediate or even necessary want.
It's just a code reading convenience to me.


> This Wednsday we have a lustre community conference call were we discuss
> upstream issues. This will need to be discussed.  

Enjoy.