All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.