lkml.org 
[lkml]   [2004]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: A Layered Kernel: Proposal
Hi Grigor.

Theodore Ts'o pretty much summed it up, but let me add a couple things...

Grigor Gatchev wrote:
>
> On Sun, 7 Mar 2004, Mike Fedyk wrote:
>
>
>>Grigor Gatchev wrote:
>>
>>>Here it is. Get your axe ready! :-)
>>>
>>>---
>>>
>>>Driver Model Types: A Short Description.
>>>
>>>(Note: This is NOT a complete description of a layer,
>>>according to the kernel layered model I dared to offer. It
>>>concerns only the hardware drivers in a kernel.)
>>>
>>
>>Looks like you're going to need to get a little deeper to keep it from
>>being OT on this list.
>>
>>What is the driver designs of say, solaris, OS/2, Win32 (NT & 9x trees)
>>and how are they good and how are they bad?
>>
>>What specific (think API changes, nothing generalized here *at all*)
>>changes could benefit linux, and why and how? Nobody will listen to
>>hand waving, so you need a tight case for each change.
>>
>>HTH,
>>
>>Mike
>
>
> Dear Mike,
>
> An year ago, I was teaching a course on UNIX security. After the
> first hour, a student - military man with experience of commanding PC-DOS
> users - interrupted me: "What is all that mumbo-jumbo about? Users,
> groups, permissions - all this is empty words, noise! Don't you at least
> classify your terminal, and issue orders on who uses it? Man, either talk
> some real stuff, or I am not wasting anymore my time on you!"
>
> Of course, I was happy to let him "stop wasting his time on me".
>

Yes, I can understand. Dealing with users as a sysadmin isn't much
different.

> Reading some of the posts here, I get this deja vu. I know the driver
> designs of some OS, and don't know others. I may waste a month or two of
> work, and post a huge description of all big OS driver models that I
> know, or waste an year of work, and give you a description of all big OS
> driver models. Will this give you anything more than what was already
> posted? Wouldn't you read my hundreds of pages, then try to summarise all,
> and eventually come to the same?

The descriptions were for my benefit, as whenever you were asked for
specific, you were a little more specific in *design* terms, not code terms.

> Or you will try to pick this from one model, that from another, and end up
> assembling a creature with eagle wings, dinosaur teeth, anthelope legs and
> shark fins, and wondering why it can neither fly nor run nor swim really
> well, why it has bad performance? This can't be, I must have misunderstood
> you.
>
> Also, does "think API changes, nothing generalised *at all*" mean anything
> different from "think code, no design *at all*"? If this is some practical
> joke, it is not funny. (I can't believe that a kernel programmer will not
> know why design is needed, where is its place in the production of a
> software, and how it should and how it should not be done.)
>

No. The designs you are talking about are *far* too generalized.
Meaning, every proposal on this list that gets anywhere is for code
modifications. You need to have your *design* proposal in *code* speak.
Anything else will just be called hand waving.

> OK. Let's try explain it once more:
>
> While coding, think coding. While designing, think designing. Design comes
> before coding; otherwise you design while coding, and produce a mess.
> Enough of such an experience, and you start believing that design without
> coding is empty words, noise. Hand waving.
>
> What I gave is more than enough to start designing a good driver model.
> After the design is OKed, details of implementation, eg. API changes, may
> be developed. Developing them now, however, is the wrong time, for the
> reasons explained just above. Let's not put the cart ahead of the horse.
>

I'm not a kernel programmer.

> Or I am wrong?

Maybe. If you can have you design describe the current linux model as
"in order to write to this SCSI disk I need to call foo(),..." and
describe your new change as "if foo() called bar() I could do...".

Basically, you need to describe everything in programming terms. A
great example is the BIO design document from Jens Axboe. That's an
example of a design before code project (but I only happened to hear
about it when 2.5.1 came out, and the code was ready to be merged...) .

Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:1.953 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site