public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@kernel.org>
To: Al Boldi <a1426z@gawab.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Designers and Builders (was: Who wants to maintain KR list for stable releases?)
Date: Thu, 30 Aug 2007 16:17:46 +0200	[thread overview]
Message-ID: <20070830141746.GC9260@stusta.de> (raw)
In-Reply-To: <200708301654.24516.a1426z@gawab.com>

On Thu, Aug 30, 2007 at 04:54:24PM +0300, Al Boldi wrote:
> Adrian Bunk wrote:
> > On Thu, Aug 30, 2007 at 07:31:24AM +0300, Al Boldi wrote:
> > > Adrian Bunk wrote
> > >
> > > > Tracking feature or implementation suggestions wouldn't make sense.
> > > > Consider e.g. that there are several people on linux-kernel who often
> > > > write what they think the kernel should do but who never write a
> > > > single line of code themselves. There's no value in tracking such
> > > > stuff.
> > >
> > > There are designers, and there are builders.
> > >
> > > Can you tell me who is more important?
> >
> > That's a distinction that doesn't exist in practice:
> >
> > Designing kernel features requires good knowledge of the area of the
> > kernel that should be changed.
> >
> > IOW: If you don't have the skills to implement it yourself you don't
> > have the skills to do any good design.
> 
> I might agree with you on this wrt hacking around the kernel, but when it 
> comes to introducing new subsystems, then we have a two fold situation:
> 
>   1.  Designing the internals of the new subsystem
>   2.  Interfacing it with the rest of the kernel
> 
> Part 1 is completely independent of the implementation, it's part 2 that 
> needs intricate implementation knowledge.

That's a perfect approach that works NOT.

Your subsystem needs to interact with the VFS or the block layer or 
whatever else parts of the kernel.

If you had ever written kernel code you would have known that your 
statement wasn't true.

> We recently had an example of this:  kexec based hibernation
> 
> So, what's wrong with tapping into people's design suggestions, and allowing 
> others to implement it?

People soon realize that you are making a fool of yourself when your 
suggestions show that you don't have a clue what you are talking about.

There's nothing wrong if this is the desired effect...

> Thanks!
> Al

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  reply	other threads:[~2007-08-30 14:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-30  4:31 Designers and Builders (was: Who wants to maintain KR list for stable releases?) Al Boldi
2007-08-30  7:32 ` Adrian Bunk
2007-08-30 13:54   ` Al Boldi
2007-08-30 14:17     ` Adrian Bunk [this message]
2007-08-30 14:50       ` Al Boldi
2007-08-30 14:31 ` Valdis.Kletnieks
2007-08-30 23:25   ` Alan Cox
2007-08-31  4:30     ` Al Boldi

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=20070830141746.GC9260@stusta.de \
    --to=bunk@kernel.org \
    --cc=a1426z@gawab.com \
    --cc=linux-kernel@vger.kernel.org \
    /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