public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleg Verych <olecom@flower.upol.cz>
To: Andi Kleen <andi@firstfloor.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Pekka Enberg" <penberg@cs.helsinki.fi>,
	linux-kernel@vger.kernel.org, mingo@elte.hu,
	vegard.nossum@gmail.com,
	Andrew Morton <akpm@linux-foundation.org>
Subject: text processing (Re: Google's Summer of Code?)
Date: Wed, 5 Mar 2008 03:01:58 +0100	[thread overview]
Message-ID: <E1JWixC-0003Ap-V2@flower> (raw)
In-Reply-To: <p73hcfm5ind.fsf@bingen.suse.de>

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

  reply	other threads:[~2008-03-05  1:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-04 18:45 Google's Summer of Code? Pekka Enberg
2008-03-04 19:35 ` Linus Torvalds
2008-03-04 19:55   ` Pekka Enberg
2008-03-04 20:05     ` Alexey Zaytsev
2008-03-04 20:23       ` Rik van Riel
2008-03-05 13:57         ` Giacomo A. Catenazzi
2008-03-05 15:38           ` Romano Giannetti
2008-03-06  8:36         ` Pekka Enberg
2008-03-04 20:13     ` Andrew Morton
2008-03-04 20:38       ` Andi Kleen
2008-03-05  2:01         ` Oleg Verych [this message]
2008-03-04 21:44       ` kernelprojects::menuconfig [was:Re: Google's Summer of Code?] Jan Engelhardt
2008-03-05  6:09         ` Willy Tarreau
2008-03-04 20:51 ` Google's Summer of Code? Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1JWixC-0003Ap-V2@flower \
    --to=olecom@flower.upol.cz \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=penberg@cs.helsinki.fi \
    --cc=torvalds@linux-foundation.org \
    --cc=vegard.nossum@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox