[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1JWixC-0003Ap-V2@flower>
Date: Wed, 5 Mar 2008 03:01:58 +0100
From: Oleg Verych <olecom@...wer.upol.cz>
To: Andi Kleen <andi@...stfloor.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "Pekka Enberg" <penberg@...helsinki.fi>,
linux-kernel@...r.kernel.org, mingo@...e.hu,
vegard.nossum@...il.com, Andrew Morton <akpm@...ux-foundation.org>
Subject: text processing (Re: Google's Summer of Code?)
Andi Kleen @ Tue, 04 Mar 2008 21:38:46 +0100:
> Andrew Morton
[]
>> http://kernelnewbies.org/KernelProjects
>>
>> There are surely many more things we could put there.
>>
>> I receive a dribble of emails about the setrlimit64/getrlimit64 one, so
>> people are looking at it, and are looking to do work. (I haven't usefully
>> responded to those emails, btw - am not sure how my name got on that one -
>> probably Ulrich would be better).
>
> http://marc.info/?l=linux-kernel&m=119981029708530&w=2
>
> is also a candidate. There are still quite a lot of unconverted
> drivers over.
And you've saw first patch there...
I'd say, that i see similar things here (LKML, kernel), wrt shell usage
and text processing.
* checkpatch instead of hard-armed editors (*The* tools of programmers),
with one's (linux, glibc, bash, whatever) source-friendly capabilities
(error/coding-style highlight, easy call-graph, param checking, security
audit(+audit scripts), etc.)
* linux-2.6/scripts/unifdef.c instead of coding style + simple script
(reinventing of compilers is a dream of CS professors of all times :)
* much of te `make` based stuff
* text processing, which is source code processing, if we are in
Open Source, has no place in
+ design (super-macro constructs --> C code),
+ auditing (stupid vmsplice() case *and* first ``fix'')
+ testing (writing source in parallel with constructing userspace
test programs, based on same source; once all is done, script
generates/constructs kernel part)
* and perl is everywhere
On my `sed` scripts i was getting (from Sam):
"Because your shell script is unreadable by normal human beings[*]
while the perl script for people with a bit of perl fu can read it
and fix/modify it.
We want tools that can be maintained and enhanced by most people.
[*] Normal human beings are people with same level of shell
scripting/sed skills that I have just to put that straight."
"Linecount is down but so is maintainability / extendability."
So, no tools or perl is better than nothing?
I don't say, i will solve Andi's quest, i just lost interest. But it is
damn interesting one! One, that many script kiddies will do in minutes,
if they would knew `sed` and a bit of UNIX practice, but not perl, C,
diff, git, etc.
So, teach youngsters about "maintainability / extendability" and "Normal
human beings", or what? OTOH, Who are teachers?
Just two points to show skill mismatch, i.e. for
+ managing/manipulating source,
+ designing, writing, maintaining correct kernel code.
Latter isn't for n00bs, right?
* multi-line grep
Andi Kleen http://mid.gmane.org/20080109000358.GF2117@one.firstfloor.org
* full and correct greping of linux style function definitions
Linus Torvalds http://mid.gmane.org/1054519757.161606@palladium.transmeta.com
All in one shot:
# print linux-style function definitions
sed -n '
/^[^[:blank:]#/].*[),]$/{
/,$/{
:_start;
N;
s=)$=&= ; t_end ; b_start;
:_end;
};
p}' kernel/*c | pager
#_____
One may not know `sed` at all (but i glad to explain and share
everything, i know), *patterns* and expressions are key things.
Once you have approved and try-and-buy tested one, everything else is
pure technical thing. Maybe somebody outstanding (like Rusty) can do that
with CPP, i don't know; `sed` is just more familiar thing for this.
Silence in reply i will understand quite right, i might be wrong. I just
can't see all that stuff not having much skilled people
involved/interested.
--
-o--=O`C
#oo'L O
<___=E M
--
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