kernelbook-feedback Mailing List for Linux Kernel Architecture Book

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi all,=0D=0A=0D=0AI think the subject explains it all. I have browsed the =
sourceforge CVS repository, but am confused...=0D=0A=0D=0AThanks in advance=
.=0D=0ASwapnil. =0A

>>>>> "C" == Christian Helmuth <ch...@ku...> writes:

    C> I just wonder if work is still in progress at this project. Can
    C> anybody give me an updated status report?  BTW: The anonymous
    C> CVS at sourceforge doesn't work.

The CVS issue is a new one, but not unbelievable: Sourceforge changed
many things during my absense, and CVS may have been one of them.

The project is not dead, it is just in a state of suspended animation.
Latest news has just been posted to the kernelbook.sourceforge.net
homepage, but the short story is that MCP has left us to our own 
devices, so that means we can now proceed with a pure free-document
license.

-- 
Gary Lawrence Murphy <ga...@li...>: office voice/fax: 01 519 4222723
T(!c)Inc Business Innovation through Open Source http://www.teledyn.com
M:I-3 - Documenting the Linux kernel: http://kernelbook.sourceforge.net
"You don't play what you know; you play what you hear." --- Miles Davis

Greetings patient kernelbook fans,

Yes, it has been a long, long time since my last update, and a lot has
happened in that space.  Among the developments, I am now the father
of one more (5 total), and I have moved quite far from direct work on
Linux.  The short story is that I have become far too busy to devote
any concerted effort to the book or wiki project; my apologies for
leaving you all in suspense all these months.

The biggest news to announce is that I have received a release from
Macmillan formalizing their departure from the project and releasing
the copyright of the work to me.  This means I am free to do as I wish
with the work, and my immediate wish is to convert the kernelbook to a
pure free license.

As of May 12, 2001, the Kernelbook will be governed by the pure,
no-options Open Publishing License and the copyright will fall to
Teledynamics Communications Inc (my company).  This is an interim
assignment until I have the documents transfered to a more common open
license (such as the GNU Free Document License) and have the copyright
transfered to some neutral agency, perhaps the FSF, or the LDP
(probably the latter).  

An important note to my contributing authors: 

   The material you have already contributed to the kernelbook source
   rightfully belongs to you and will be removed at your request.  I
   also return the copyright to you, but ask that you formally grant
   this copyright to Teledynamics Communications Inc so that we can
   then grant the whole work over to the neutral agency.  Any material
   which has not been transfered will be removed at that time.

Some of you may have noticed new software being used for the KernelWiki
and, unfortunately, some of you have reported that this software does
not work with your browsers.  I hope to correct this situation as soon
as possible; before the millenium crash of the KernelWiki, it was
a very active and vital resource and is desperately in the kernel
community.

-- 
Gary Lawrence Murphy <ga...@ca...>  TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless.  They can only give you answers."(Pablo Picasso)

Hi,

I just wonder if work is still in progress at this project. Can anybody give
me an updated status report?
  BTW: The anonymous CVS at sourceforge doesn't work.

Ciao,
Christian.

On page 6 of chapter 6 (in the PDF format), it says "Bug reports are cruc=
ial=20
Linux developers"; that should probably be "are crucial _to_ Linux=20
developers".

On chapter 1, page 2 (PDF), I think it should be "hybrids begot" rather t=
han=20
"hybrids begot".

On page 3, there's "Unix was rapt with license wars an infighting".  Unle=
ss=20
you mean to say that the Unix world was deeply concerned with these thing=
s, I=20
think that you should use another word, like maybe "reft", though that's =
a=20
bit archaic.  Also on page 3, "one reason ... chose to implement Unix in =
a=20
high level language to achieve a level of abstraction...", I think that=20
should be "was to achieve" or "was in order to achieve".

The header "Planned features for Linux 2.5" is on page 9, while the conte=
nts=20
are on page 10; a header should always be followed by at least one paragr=
aph=20
of whatever it heads.

Since I haven't looked at the full RTF version of the book, I don't know =
how=20
you do the bibliography (or if there is one yet), but I think it might be=
 a=20
good idea to put a little bibliography (especially URLS) at the end of ea=
ch=20
chapter.

Finally, I like the sense of humor displayed in the first two paragraphs =
of=20
the first chapter; technical documentation with wit is a good thing, in m=
y=20
opinion. ;-)

--=20
Matthew Cline        | Suppose you were an idiot.  And suppose that
ma...@ni... | you were a member of Congress.  But I repeat
                     | myself.  -- Mark Twain

Hey guys...just found this project and wanted to find out what the current
status of it was.

I was wondering if you had considered having something of a sub-editors who
have some expertise in each area to verify any changes that may take place
on the wiki documentation.  I would hate for someone to just go there and
say something like "a kernel something popcorn comes from".

Do you currently have any ideas of the sections that need extensive work on?

What sort of diagram tool are you planning on using?  Something like dia?

Any chance of having some form of nightly/weekly snapshot version of the
current work (which might be dynamically generated if the wiki stuff is in
someway cvs based)?  I know I could probably get a lot of it from the cvs
tree - does it still work?  How does it compare to the wiki work?  Is the
wiki work in someway cvs based?  In other words...is it possible to revert
back to previous versions, in case someone nukes a major important section.

I look forward to hearing from you guys.

Eric Bresie
eb...@us...

The following message is a courtesy copy of an article
that has been posted to comp.os.linux.development.system as well.

Yes kernel fans, it's Gary's nag-the-kernel-list time once again.

November 1 is "Dia de Muertos", the Day of the Dead, the time for
visiting tombstones and honouring our ancestors.  A time when the dead
and gone can live through the words and deeds of the living.

The November 2000 KernelWiki Challenge is ...

"The _____ in the _____ subsystem implements the old _____."

1) Fill in the blanks, short and sweet, in your own words.

2) Go to http://kernelbook.sourceforge.net/wiki/?KernelWiki and find
   the KernelWiki page covering your area of expertise.

3) Click the "Edit this Page" link

4) Plunk your November KernelWiki response into the text box.

5) Click "Save" and get back to your happy hacking.

It's painless. All I want is 10 minutes of your time.  You know you
know the answers, and if you don't, you know the proper questions to
ask. I don't know how I can make it any easier.  10 minutes, 15 tops.

It takes longer to flame me for nagging, and contributing is more
positive.

No excuses. _Everyone_ has that kind of time to spare for Linux
documentation. There are hundreds of competent engineers active on
this list. One day's worth of our collective linux-kernel effort,
focused precisely on illuminating some part of the code, would
complete several chapters of text. A week's worth would fill a
thousand pages.

What do you win?  Do it right, and you might cause that "transmission
of light" which nets you assistance in your kernel hacking.  What
goes around, comes around.  'Karma' means 'action'.

WARNING: I am going to persist in nagging you to participate, but no
more than once a month ;) Chide me, ignore me, put me in your kill
file if you will but the KernelWiki _is_ working.

KernelWiki is a smash hit. KernelWiki is an overnight success.
KernelWiki has exceeded all expectations.  KernelWiki is the latest
craze, the subject of folk songs and Paris fashions.  Be the first in
your network segment to KernelWiki!

If you have more than 15 minutes to spare and you are interested in what
it is that I'm up to with this KernelWiki thing, you are invited to read

        http://kernelbook.sourceforge.net/wiki/?KernelWikiWhy
        http://kernelbook.sourceforge.net/wiki/?KernelWikiPolicies
        http://kernelbook.sourceforge.net/wiki/?HowToUseWiki

The diligent are invited to cruise KernelWiki for question marks
and click the mark to describe the undefined term.  KernelWiki 
depends on your kind contributions.

See you in December ;)

-- 
Gary Lawrence Murphy <ga...@li...>: office voice/fax: 01 519 4222723
T(!c)Inc Business Innovation through Open Source http://www.teledyn.com
M:I-3 - Documenting the Linux kernel: http://kernelbook.sourceforge.net
"My humanity is bound up in yours; we can only be human together"(Tutu)

This is a preview announcement of the Kernel Documentation WikiWiki I
have just added to the Kernelbook website.  For those who have not
used a WikiWiki before (WikiWiki is the Hawaiian word for "quick") it
is an ultra-fast method for compiling knowledge into a dialog.  It's
somewhat like a FAQ-o-matic, only it is so simple, real people can
actually use it.

So please do ;)

http://kernelbook.sourceforge.net/wiki

There's not much meat on it, but I had to start somewhere; The current
map uses the KernelBook TOC as a rough framework to organize
contributions. This is only a starting point: Being a Wiki, it can go
any way it needs to go.

Everyone is welcome to participate, there is no login, no access code,
and all material on the Wiki will be covered under the strictly free
Open Content license --- everyone is free to plunder it as, say, raw
material for their book ;)

Over the weekend, unless there are some major show stoppers with the
PHP code, I will announce the Wiki on the linux-kernel and on cola ---
if you spot any crash-points, please let me know.

-- 
Gary Lawrence Murphy <ga...@ca...>  TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless.  They can only give you answers."(Pablo Picasso)

Yes, this list has been quiet ;) and my apologies for this; here
is a brief update on where we are and where we are going with this
kernelbook project.  

Put another way, here is my List of Top Ten Lame Excuses:

1) We've had several more contributing authors leave us over the
copyright/license issue, and while regrettable, it is an issue out of
my control --- the MCP/OPL was the best we could do, and it is a far
sight better than any previous commercial publishing license. It is
the perogative of all authors to do as their conscience dictates and I
respect their decisions, but we are now short of the expertise needed
for the indepth chapters of the book.

2) My own contributions are stalled due to lack of resources; the time
and hardware commitments exceeded my budgets and as a result, I am
forced to put my involvement on hold while I build up the bank
accounts.  While MCP does fund our writing, we are on our own for our
research, and I have asked our publisher to let us hold off on
committing to a writing schedule until we have a comprehensive
collection of the raw material.  While the Rigi project and others
have been fantastically supportive of my efforts, I can only do so
much on my own and must consider my own bottom line.

3) Linux 2.4 is also maturing much later than anyone expected and
already large parts of what has been contributed to the book are now
obsolete.  Many core sections are still in flux; if I may coin a new
phrase, I'd say they are "pulling a TomCat" ;) (this is an inside joke
to Apache/Tomcat users) To avoid releasing a book only to have it
obsolete before it hits the shelves, I have asked that we wait until
the first public release of 2.4.0 before we run any further analysis.

4) We are not receiving any public contribution to the book.  A
handful of contributors and feedback-list members have provided
fantastic reviews and feedback, and the project is featured on several
kernel websites (such as Kernel Newbies) but I have failed to ignite
the enthusiasm of precisely the people we need. I also have a secret
hope that the kernel developers are all under the gun to complete this
new revision and have little time left to grace us with their support
until 2.4 is released. 

5) Over the delays on the licensing/copyright issues (we have now been
working on this book for just over one year) several contributing
authors have vanished off the face of the earth; only a very few have
actually received and returned their contracts.  We need to mount a
fresh campaign to re-staff the core team.

6) Several excellent free-document initiatives have appeared for the
kernel.  The linux-doc mailing list has resurfaced, kernel-doc and
kernelnewbies have become more active, and the Documentation/Docbook
is growing.  Our book is not a competitor to these projects, since our
scope is to chart the architecture whereas these works chart the APIs
and component-level algorithms.  However, the expanding scope of these
free document projects, and the defection of some of our authors over
to these projects ;) means our table of contents must be rethought to
make this distinction.  I am also talking with MCP about incorporating
the best of these free documents into an appendix of the book so we
can cross reference and index them (also many people cannot print raw
DocBook sources).

        While I applaud and participate in these free document
        initiatives, I personally believe the style and direction of
        such documents are very different from a professionally edited
        trade publication; while we are free to include their material
        into our book, the unfortunate side effect of their free
        document methods is that we cannot apply editorial standards
        to maintain the requisite consistency of scope and style ---
        basically, it is free, it is a gift and you take what you get.

7) On a more pragmatic issue, DocBook SGML proved inadequate to our
process needs.  To go smoothly from authoring through editorial to
typesetting, we must shift to DocBook XML.  Unfortunately, I was only
just beginning to get a grasp of the SGML tools and the fine art of
DSSSL and OpenJade, but now I must re-learn the technology from
scratch ... and here again, I ran out of personal resources to be able
to devote the time to learn the new methods and then to apply them.
Considering the friction I received from most contributing authors
over using DocBook in the first place, I am also not looking forward
to dragging them kicking and screaming into XML ;) One a positive note
for the readers of the feedback-list, moving to XML will also simplify
creating the HTML editions of the chapters, which is the number one
most requested service.

8) Due to (6) and (7) the CVS archive is broken, stuck in a transition
between folding in the kernel Documentation/DocBook appendix (which
requires heavy forking to be incorporated into a book and thus becomes
a maintenance problem) and the transition to XML.  There are
techniques used in our SGML which are unsupported in DocBook XML, and
I have just haven't had the time or money to do all the conversion
work myself.  Since only two contributing authors even attempted to
use this authoring process, it didn't seem a very high priority, but I
do apologize for having frustrated those potential reviewers who went
through the trouble of downloading the book only to discover that it
did not build.

9) Somewhat related to (8) is the issue of diagrams and images.  The
makefile is also broken with regard to images and was not fixed
because my experience working with a large book-sized SGML source
quickly underlined shortcomings in the labelling conventions and
directory structure which require some careful thought.  We have also
learned that the end-to-end XML process is most friendly to postscript
images and since this is an architecture book, line drawings are
probably all that we need, but it does mean we have some bitmaps to
weed out of the text.

10) Last of my lame excuses is psychological: After spending two
months of overtime 7-day-weeks, wasting my summer sifting relational
kernel facts and building LXR tables, I saw many postings on the
linux-kernel list emphatically opposing any such attempts to make the
kernel accessible. Some of the most adamant anti-tools comments come
from Linus himself.  As I began to burn out, and as my bank balance
dwindled, I began to ask "Why am I doing this?"  There's no prize at
the end, the royalties will be minimal (it is not, after all, a new
Harry Potter book), the developers don't want it, the authors don't
like the methodology, the open source people won't endorse it, and
users might buy it, but none are knocking on my door to help make it
happen. Is life too short for all this bother?  As a result, I took
three weeks off to play on the beach with my kids and ponder whether I
had the proper charisma to make this thing work.

Anyway, such as it is, that is the current status of the Kernelbook.
Rumours of its death are greatly exaggerated, but do not expect to see
great leaps of progress any time soon.  Maybe it is like the "Instant
Giant Sequoia Tree" where you just plant the seed, add water, wait 750
years, and then stand back ;)

-- 
Gary Lawrence Murphy <ga...@li...>: office voice/fax: 01 519 4222723
T(!c)Inc Business Innovation through Open Source http://www.teledyn.com
M:I-3 - Documenting the Linux kernel: http://kernelbook.sourceforge.net
"You don't play what you know; you play what you hear." --- Miles Davis

Some comments & feedback

1) I think it makes easier reading it the NOTES are on the same page as
the reference only because I am a lazy person and don't want to turn the
pages. see pages 2 & 5
2) Does it make sense to have a glossary of terms?? e.g. LFSR & CSN
3) The explanation of the function vars seemed to blend in with the
description.  I think they should standout somehow.
4) There are periods at the beginning of the middle paragraph on page 16
and first paragraph on page 18 and the word "routine." on page 17.  It
looks as if they belong to the previous sentence???

All-in-all I thought it was a very good chapter.

cheers,

-- 
===========================================================================
Armin Kuster                 MontaVista Software Inc.
Customer Support Engineer    790 Potrero Avenue
Phone (408) 328-0305         Sunnyvale CA 94086
Fax   (408) 328-9204         e-mail: ak...@mv...
web: www.mvista.com          
===========================================================================

I'd really like to see a discussion of tty handling: drivers, line
disciplines, consoles, etc.
This is omitted from virtually every Linux kernel document out there with
the exception
of the very difficult to read book by Remy Card.

    ... phil hutto, Emory University and Georgia Tech
    ... pw...@ma... pw...@cc...

I have just checked the Tom Lees chapter on Plug and Play into the CVS
archive and have uploaded review PDF editions of the PnP and Sources
chapters to the FTP site.

I have also updated the pkbib.sgml file to partition the bibliography
into sections; Tom had included his bibliography material at the end
of his source file and I have also added references from my own
chapters; one large bibliograph would get woefully out of
control. Right now it is not really sorted in any shape or form, but
this partitioning will let us sort the entries in our review copies,
and make it easier if MCP decides to break them up to put references
at the end of each chapter.

-- 
Gary Lawrence Murphy <ga...@ca...>  TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless.  They can only give you answers."(Pablo Picasso)

I have placed three chapters into the anonymous FTP archive at
ftp://kernelbook.sourceforge.net/pub/kernelbook

These chapters are:

        ch-intro.pdf    - Chapter 1
        ch-tools.pdf    - Kernel programming and debugging tools
        ch-contrib.pdf  - Contributing to the kernel project

Feedback is welcome, encouraged and essential.

-- 
Gary Lawrence Murphy <ga...@li...>: office voice/fax: 01 519 4222723
T(C)Inc Business Innovations through Open Source http://www.teledyn.com
M:I-3 - Documenting the Linux kernel: http://kernelbook.sourceforge.net
Free Internet for a Free O/S? - http://www.teledyn.com/products/FreeWWW

Nothing like giving feedback on your own work ;) ... latest news from
ESR suggests the kernelbook will need to include a section on adding
new options to the kernel using the CML2 configuration as well as
through the legacy kbuild.

Q: Should we even bother with kbuild?  Perhaps just dismiss it quickly
   and concentrate on CML2?  CML2 is not in the 2.4-test1 release and
   likely won't get into the kernel until 2.5 since verifying the new
   method against the nightmare tangle of kbuild will be a significant
   effort.

Q: Where should the CML2 tutorial go?  Into "Contributing to the Kernel"
   or into "Kernel Sources" ... or someplace else?  There's not enough
   to it to fill a new chapter, but it will be a largish section within
   a chapter.

For more information on CML2, see http://www.tuxedo.org/~esr/kbuild/

-- 
Gary Lawrence Murphy <ga...@ca...>  TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless.  They can only give you answers."(Pablo Picasso)

Kernelbook: Checkpoint review release 0.1

https://sourceforge.net/project/filelist.php?group_id=4387

   This file is the initial preview release of three chapters and the
   TOC for The Linux Kernel; this is only available as an RTF file and
   is intended as a review copy for editors and technical review. The
   document includes chapters 4-6 on kernel tools, contributing to the
   kernel project and Richard's chapter on the Linux sources (not yet
   updated to 2.3).

   Download: http://download.sourceforge.net/kernelbook/kernelbook-0.1.rtf

   Please direct all feedback directly to the chapter authors or to the
   kernelbook-feedback mailing list; for more information on the
   kernelbook project, please visit The Kernelbook Homepage at
   http://kernelbook.sourceforge.net

-- 
Gary Lawrence Murphy <ga...@ca...>  TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless.  They can only give you answers."(Pablo Picasso)

Hi Holger,

Thanks for the comments!  I will make the corrections to the CVS
editions later today.

>>>>> "h" == holgerschurig  <hol...@gm...> writes:

    h> all: html pdf ps rtf txt
    h> html: $(HTMLDOC) ...

Easily done.  I had actually intended the Makefile to be used with
command lines like "make prokernel.rtf" to make a specific print, but
it is no extra work to add the rules you state.  I also noticed only
last Friday that dvi2pdf is not part of any distro (it is just
something I had collected long ago) --- I have put this script into
the ftp archive.

    h> Missing pictures ---------------- After I made the html
    h> documention I saw that the pictures where not included. At
    h> least "note.gif" is not there. I'd also suggest that you
    h> convert that to *.PNG --- gif is not a free format when the
    h> pictures use lzw compression.

Another oversight --- these are icons provided by the stylesheets; I
will also put a tar of these images into the FTP archive.

Norm only provides GIF files and the stylesheets reference these - to
convert to PNG would require developing and maintaining a forked
edition of his stylesheet package.  Also, I had some trouble with my
PNG conversion software and hence left my images at GIF; I like PNG as
a format, but if ESR is so adamant about our using GIF, he should
update his tools more often than once every 3 years ;)

Another problem with PNG is in going to production: Our editorial
review and typesetting processes will not understand PNG, and there
are still many browsers which do not, including many versions of
Netscape for Linux --- all of these machines understand GIF.  The only
alternatives for production which are also supported on Linux are BMP
and PCX formats, both of which produce unbearably large bitmap files.

I understand the patent concern, but I come from a background in art
and folk music where we long ago realized boycotts do not work; they
only hurt the consumer, not the agency which is perpertrating the
problem.  Even folk-superstar Pete Seeger now sees boycotts as naive
and as _serving_ the target company's interests more than it forces
change.

I studied the art of 'civil-disobedience' during my association with
the American composer John Cage and later with Udo Kasements; both
men were close friends of Marcel Duchamp.  Here is perhaps a relevent
story: When John Cage was granted a Guggenheim Fellowship award, he
received a form which included swearing to the statement "I will never
try to overthrow the government of the United States".  John was in a
dilema.  He needed that money, but could not sign such a
freedom-limiting statement.  He called Max Ernst who told him, "Sign
the papers ... and continue spreading joy and revolution everywhere".

If we use GIF rampantly, everywhere, at every opportunity, and if we
all flaunt our violation of their patent in the face of the patent
holders every time there is a court issue, Compuserv will loose their
right by shear weight of our civil disobedience against them.  If we
bind together, send money to any company being sued and show up in
numbers to insist we be charged along side of them, Compuserv will go
broke just serving us all with suppoenas. They cannot take us all to
court.  To reform a bully, we must provoke them into a fight they
cannot win.

The GIF restriction is untennable.  Like all software patents, it is a
bad law. But we can never force a bully who benefits from such laws to
change any law that sustains their power and control, we must force
change in the law itself first.  We cannot do this through a boycott.

-- 
Gary Lawrence Murphy <ga...@ca...>  TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless.  They can only give you answers."(Pablo Picasso)

Hi All,

I will also be at LinuxWorld if you would like to talk to me about MCP, the kernel book project, or any other book ideas you have knocking around.  I will be at the BOF, and am likely to be in the general vicinity of Gary if you can't find me.

Cheers

William E. Brown
Acquisitions Editor
SAMS Publishing
Wil...@ma...
ph:  800-571-5840 ext.4506
local:  317-581-4506
fax:     317-581-4770

-----Original Message-----
From: ker...@li...
[mailto:ker...@li...]
Sent: Friday, May 12, 2000 1:13 AM
To: ker...@li...
Cc: ker...@li...
Subject: [Kernelbook-authors] LinuxCanada Expo in Toronto

If anyone is attending the LinuxCanada Expo in Toronto next week, I
have secured a room for a "Documentation BOF" at 6pm Monday; you're
cordially invited to drop by.  I will also be at the Expo from Monday
to Wednesday, likely near the MCP, CLUE and/or LDP booths; hunt me
down if you'd like to chat about the book, docbook, MCP, the LDP or
just documentation.

-- 
Gary Lawrence Murphy <ga...@ca...>  TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless.  They can only give you answers."(Pablo Picasso)

_______________________________________________
Kernelbook-authors mailing list
Ker...@li...
http://lists.sourceforge.net/mailman/listinfo/kernelbook-authors

If anyone is attending the LinuxCanada Expo in Toronto next week, I
have secured a room for a "Documentation BOF" at 6pm Monday; you're
cordially invited to drop by.  I will also be at the Expo from Monday
to Wednesday, likely near the MCP, CLUE and/or LDP booths; hunt me
down if you'd like to chat about the book, docbook, MCP, the LDP or
just documentation.

-- 
Gary Lawrence Murphy <ga...@ca...>  TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless.  They can only give you answers."(Pablo Picasso)

>>>>> "p" == pvlad  <pv...@bi...> writes:

    p> what type of technical resources needed how does a project plan
    p> look for such a project (time for design, implementation,
    p> testing) -- just approximate estimates that come from one of
    p> the implementations with average complexity.  

Yes, this is probably out of the scope of this book, although the
chapter on tools could add a little of what you want.  I stuck with
only listing those tools essential to actually working on the kernel
rather than those project management things that are common to any
large project.

    p> As far as the 'reference' section is concerned -- I would agree
    p> that it is better to have separate from the main book.  

I tend to agree, but the kernel-doc project is integrating them. 

I'd like them as two different (cross-ref'ed) books as I would use
both differently --- with other API books, I find I am always picking
it up only to read the API section whereas, as you say, a beach is a
good place for a tutorial (I live on a beach)

I suppose I can take the paperback and just split the spine of it ;)

-- 
Gary Lawrence Murphy <ga...@te...> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
Free Internet for a Free O/S? - http://www.teledyn.com/products/FreeWWW/
"Computers are useless.  They can only give you answers."(Pablo Picasso)

Addition:
In the section where I was suggesting to provide guidelines
on how much time it would take to develop a kernel
driver -- I think my thought was incomplete.
What I was thinking at that the time was the fact that for
a person who just started working with the kernel it
would be nice to have some pointers on how to manage
such a project:
what type of technical resources needed
how does a project plan look for such a project 
(time for design, implementation, testing) -- just
approximate estimates that come from one of the implementations
with average complexity.
It looks like the type of material you are preparing
is strictly technical and is not designed to help
in project management for Linux kernel related
projects -- so may be my suggestion does not belong here.

As far as the 'reference' section is concerned -- I would agree
that it is better to have separate from the main book.  This way
the printed version of the main book can be taken to read on the
beach, on the plane, at a conference (if it is too boring :-) ).

Vladislav

On Wed, 10 May 2000, Gary Lawrence Murphy wrote:
> Thanks for the comments --- and have no fear: I will be saving them
> all for careful consideration ;)
> 
> >>>>> "C" == Chongkyoon, Rim <her...@se...> writes:
> 
>     C> On Tue, 9 May 2000 pv...@bi... wrote: |Hello, |here are
>     C> my suggestions to the kernel book: | |1) a topic on how to
>     C> convert existing drivers |from FreeBSD (or other OpenBSD,
>     C> NetBSD),WinNT, W95 to Linux |
> 
>     C> It's very interesting and necessary topic. But I think it's not
>     C> about the kernel itself. Probably a new book about the Linux
>     C> device driver is necessary.
> 
> I agree with both points ;) 
> 
> I'd included porting from NT->Linux and we hopefully have people from
> CreativeLabs working on that chapter, but it is very true that porting
> from BSD/SCO would also be useful; it's not the focus of the book, but
> I think it fits in with the general theme of "How do you _use_ the
> kernel sources".
> 
> I do know Alessandro is working on an update to his book, so that will
> probably cover the general topic of device drivers.  Our task is more
> on the functional specs for the existing driver types, how they communicate
> with the kernel.  "How long" is an interesting question; if the Device
> Driver Toolkit is updated for 2.4, the time to complete a module can be
> cut way down, but without it, you can expect to add a day or two to
> distill an existing driver down to a template.  It's a very hard
> call to make mostly because the 'module' part of your code is very
> small compared to the 'what it does' part, and the latter part can
> be as simple as echoing to a port (as in the voice synth) or as
> complex as rasterizing images for driving a plotter.
> 
> Thanks for those other points; the macros is a good point and belongs
> in the "Speaking Kernel" chapter; there is a section there on Kernel
> DEFINEs and the more global of these will be in there; those specific
> to various areas will go into those other chapters.
> 
> We're still toying with adding a 'reference' section which simply
> lists APIs as man-page like listings, much like you find in the middle
> of the Perl book; Tim Waugh's kernel-doc utility can generate these
> automatically (if we massage all the kernel files for GNOME-style comments).
> It would add tremendous bulk to the book, but I often find that these are
> the sections I use the most on those other books --- now, in Perl or
> DocBook, those sections are a small fraction the size of what it would
> be in the Kernel, so I wonder, would it really be useful?  Or would it
> be more useful to have the book stay at the block-diagram level and just
> include these reference pages on CD?
> 
> I still need an author for the porting-Linux chapter.  My original author
> had to leave the project and its pretty rare to find someone who really
> follows that issue and understands what was required to get from the i86
> to even strange platforms like the Sparc or the Mac.  If you have any
> recommendations, please let me know.
> 
> -- 
> Gary Lawrence Murphy <ga...@te...> TeleDynamics Communications Inc
> Business Innovations Through Open Source Systems: http://www.teledyn.com
> Free Internet for a Free O/S? - http://www.teledyn.com/products/FreeWWW/
> "Computers are useless.  They can only give you answers."(Pablo Picasso)
> 
> 
> 
> _______________________________________________
> Kernelbook-feedback mailing list
> Ker...@li...
> http://lists.sourceforge.net/mailman/listinfo/kernelbook-feedback
-- 
..

Thanks for the comments --- and have no fear: I will be saving them
all for careful consideration ;)

>>>>> "C" == Chongkyoon, Rim <her...@se...> writes:

    C> On Tue, 9 May 2000 pv...@bi... wrote: |Hello, |here are
    C> my suggestions to the kernel book: | |1) a topic on how to
    C> convert existing drivers |from FreeBSD (or other OpenBSD,
    C> NetBSD),WinNT, W95 to Linux |

    C> It's very interesting and necessary topic. But I think it's not
    C> about the kernel itself. Probably a new book about the Linux
    C> device driver is necessary.

I agree with both points ;) 

I'd included porting from NT->Linux and we hopefully have people from
CreativeLabs working on that chapter, but it is very true that porting
from BSD/SCO would also be useful; it's not the focus of the book, but
I think it fits in with the general theme of "How do you _use_ the
kernel sources".

I do know Alessandro is working on an update to his book, so that will
probably cover the general topic of device drivers.  Our task is more
on the functional specs for the existing driver types, how they communicate
with the kernel.  "How long" is an interesting question; if the Device
Driver Toolkit is updated for 2.4, the time to complete a module can be
cut way down, but without it, you can expect to add a day or two to
distill an existing driver down to a template.  It's a very hard
call to make mostly because the 'module' part of your code is very
small compared to the 'what it does' part, and the latter part can
be as simple as echoing to a port (as in the voice synth) or as
complex as rasterizing images for driving a plotter.

Thanks for those other points; the macros is a good point and belongs
in the "Speaking Kernel" chapter; there is a section there on Kernel
DEFINEs and the more global of these will be in there; those specific
to various areas will go into those other chapters.

We're still toying with adding a 'reference' section which simply
lists APIs as man-page like listings, much like you find in the middle
of the Perl book; Tim Waugh's kernel-doc utility can generate these
automatically (if we massage all the kernel files for GNOME-style comments).
It would add tremendous bulk to the book, but I often find that these are
the sections I use the most on those other books --- now, in Perl or
DocBook, those sections are a small fraction the size of what it would
be in the Kernel, so I wonder, would it really be useful?  Or would it
be more useful to have the book stay at the block-diagram level and just
include these reference pages on CD?

I still need an author for the porting-Linux chapter.  My original author
had to leave the project and its pretty rare to find someone who really
follows that issue and understands what was required to get from the i86
to even strange platforms like the Sparc or the Mac.  If you have any
recommendations, please let me know.

-- 
Gary Lawrence Murphy <ga...@te...> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
Free Internet for a Free O/S? - http://www.teledyn.com/products/FreeWWW/
"Computers are useless.  They can only give you answers."(Pablo Picasso)

On Tue, 9 May 2000 pv...@bi... wrote:

|Hello,
|here are my suggestions to the kernel book:
|
|1) a topic on how to convert existing drivers
|from FreeBSD (or other OpenBSD, NetBSD),WinNT, W95 to Linux
|

It's very interesting and necessary topic. But I think
it's not about the kernel itself. Probably a new book 
about the Linux device driver is necessary. 

-- 
-----------------------------------------------------
#include <freedom.h>
struct freedom *mine = getfreedom(50); /* 50 years */
>> Permission denied!

Hello,
here are my suggestions to the kernel book:

1) a topic on how to convert existing drivers
from FreeBSD (or other OpenBSD, NetBSD),WinNT, W95 to Linux

2) if possible, it would good to select one of the well-known
OS theory books and refer to it for more generic theoretical concepts
Like, in general memory management, and then this book would
contain details on why linux uses slab scheme and how it is
exactly implemented

3) it is also would be good to take one of the well implemented
device driver or file systems and first explain
generic concepts (using easy to understand diagrams) and then 
show the details of the implementation.  It would also
be nice to show how long each part of that device driver/or
whatever took to implement, what difficulties where encountered.
I am pointing this out because, if I am planning to build
a device driver or a special file system (assuming that
I have never done it before), I would like to have guidelines
on the estimated time of completion so I can correctly manage
expectations of my customers/users.

4) Ports to new architectures.  This chapter would contain the
information on what kernel components need to be added/modified
to have a basic linux kernel (with just ide, keyboard, console, 
floppy drive) working on a new HW platform (that is at least
32 bit and supports VM)

5) coding conventions (not styles, but more about macros, what
should be implemented as a macro, how it is named, where it
should be located, etc).  Lately,
I tried, but was not successful in understanding to 
what CPU  macro 'current' is set to, and how exactly it is being
set and when (and who does it and why).

That's my input for now :-)

Regards,
Vladislav

2000	Jan	Feb	Mar	Apr	May (10)	Jun (1)	Jul (3)	Aug	Sep (2)	Oct	Nov (2)	Dec
2001	Jan	Feb (1)	Mar (1)	Apr	May (2)	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec