Re: [Kernelbook-feedback] suggestions for the book

[<pv...@bi...>]

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
-- 
..