Prev: [PATCH 24/25] staging/wlags49_h2: remove casts from void*
Next: block: implement an unprep function corresponding directly to prep
From: Justin P. Mattock on 1 Jul 2010 09:40
On 07/01/2010 12:58 AM, Arnd Bergmann wrote:
> On Thursday 01 July 2010 00:09:45 Justin P. Mattock wrote:
>> Hopefully correct, as request move the function that checks
>> if userspace is using kernel headers, from kernel.h to types.h.
>> (Please check.)
>>
>> Signed-off-by: Justin P. Mattock<justinmattock(a)gmail.com>
>
> Trivial change: The 'Signed-off-by'-line should start at the beginning
> of the line, no space in front of it, to make all tools parse
> it correctly.
>
o.k.

> Also, the text above should really be the changelog in the way
> that you want it to appear in the git history. The explanatory
> text about what has changed can go below the '---' line, together
> with the diffstat information. Git only uses text above the line
> as a changeset comment.

cool thanks for the tid bit of info on how git reads these patches
(also later down the line, I'll have to figure out how to have
thunderbird copy/past patches properly so that life can be easier). .

>
>> --- a/include/linux/types.h
>> +++ b/include/linux/types.h
>> @@ -179,6 +179,12 @@ typedef __u32 __bitwise __wsum;
>> typedef unsigned __bitwise__ gfp_t;
>> typedef unsigned __bitwise__ fmode_t;
>>
>> +#ifndef __EXPORTED_HEADERS__
>> +#ifndef __KERNEL__
>> +#warning "Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders"

so this is legit with the length of the statement? or should this be
broken down into a small quick line directing to a file with the address
or something

>> +#endif /* __KERNEL__ */
>> +#endif /* __EXPORTED_HEADERS__ */
>> +
>> #ifdef CONFIG_PHYS_ADDR_T_64BIT
>> typedef u64 phys_addr_t;
>
> Good: No more linewrap, correct use of quotation marks.
> Bad: This is now inside of #ifdef __KERNEL__, so it can never be caught by
> the compiler. Even if it looks like a trivial patch, it's a good idea
> to test it.
>

thats probably why this wasnt firing off, before I had sent it out I
though twice about it, but then figured better to get it out there, then
go from there.

> I'd suggest putting the #ifndef __EXPORTED_HEADERS__ into a new #else
> path of the last #ifdef __KERNEL__ of this file.
>

alright.. I look into this and resend

> Anyway, thanks for the persistence, I know it's frustrating when a one-line
> change goes through half a dozen revisions.
>
> Arnd
>


it does seem frustrating, but honestly I am actually excited to do such
a thing, main issue is energy i.g. doing this when/after spending hours
already is a bit intense...

Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Justin P. Mattock on 1 Jul 2010 12:00
On 07/01/2010 08:07 AM, Arnd Bergmann wrote:
> On Thursday 01 July 2010, Justin P. Mattock wrote:
>>>>
>>>> +#ifndef __EXPORTED_HEADERS__
>>>> +#ifndef __KERNEL__
>>>> +#warning "Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders"
>>
>> so this is legit with the length of the statement? or should this be
>> broken down into a small quick line directing to a file with the address
>> or something
>
> Yes, the length of the statement was never the problem, it only went wrong
> because the // in the url gets interpreted as the start of a one-line comment.
>
> Arnd
>

alright.. then I'll look at getting this resent today.

Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Justin P. Mattock on 1 Jul 2010 13:30
o.k. I resent an updated version. keep in mind this is a bit confusing
with the __KERNEL__ being in there multiple times, but with the v2 I'm
able to see the #warning message with my little program.

As for the patch itself hopefully I corrected it's changelog etc..
lately I've been a bit confused with the whole sighned off thing i.g.
you suggested the #else so naturally I should add your name with a
sighned off, but with other patches I was told not to do so due to the
sighned off procedure/process. I'll re-read the submitting patches again
to make sure.

hopefully I get this right..

Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Justin P. Mattock on 1 Jul 2010 17:40
On 07/01/2010 01:38 PM, Arnd Bergmann wrote:
> On Thursday 01 July 2010, Justin P. Mattock wrote:
>> o.k. I resent an updated version. keep in mind this is a bit confusing
>> with the __KERNEL__ being in there multiple times, but with the v2 I'm
>> able to see the #warning message with my little program.
>
> Well, it's technically correct, but the #ifndef __KERNEL__ in there
> would better get dropped, since you are already in the #else path.
>

ahh.. I see now(makes sense). I resent this with the above change.

>> As for the patch itself hopefully I corrected it's changelog etc..
>> lately I've been a bit confused with the whole sighned off thing i.g.
>> you suggested the #else so naturally I should add your name with a
>> sighned off, but with other patches I was told not to do so due to the
>> sighned off procedure/process. I'll re-read the submitting patches again
>> to make sure.
>
> You got that part right. The S-o-b only ever gets added by a person
> sending a patch for the sending address, so you would not add my
> address as S-o-B, though you could add it as Cc:.
> When someone picks up your patch and forwards it, that person
> will add his/her own S-o-b line below yours and keep you listed
> as From.
>
> Arnd
>

o.k. I added a Cc, then down the line the sob's are added etc.

Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH 24/25] staging/wlags49_h2: remove casts from void*
Next: block: implement an unprep function corresponding directly to prep