I am interested in reviewing the technical specifications on the Linux kernel VM.
As there has been much controversy of late on this subject, it would be relevant to compare the concepts behind both the former VM and the new VM in order to obtain a better understanding of the issues.
Is there a ?white paper? available on both the old and the new VM?s?
Understandably, the VM is a work in progress; however, there should be a basic set of design goals and concepts from which future development will proceed. It would definitely be helpful to present them both as an aid to further analysis.
Sincerely,
D. L. Beaman
-- D. L. Beaman --
Software development
Global Digicom
----------------------------
[email protected]
I found this: http://www.nks.net/linux-vm.html
I hope it helps.
Sincerly,
David Beckett
__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com
On 23 Jan 2002 [email protected] wrote:
> I am interested in reviewing the technical specifications on the Linux
> kernel VM. As there has been much controversy of late on this subject,
> it would be relevant to compare the concepts behind both the former VM
> and the new VM in order to obtain a better understanding of the
> issues. Is there a ?white paper? available on both the old and the
> new VM?s? Understandably, the VM is a work in progress; however,
> there should be a basic set of design goals and concepts from which
> future development will proceed. It would definitely be helpful to
> present them both as an aid to further analysis.
I made a paper about the old VM in the 2.4 kernels, with some
overview of its shortcomings and what needs to be fixed.
This paper was made for last year's USENIX in Boston, you can
get it from my home page:
http://surriel.com/lectures/
regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
On Thu, 24 Jan 2002, Denis Vlasenko wrote:
> On 24 January 2002 01:36, [email protected] wrote:
> > I am interested in reviewing the technical specifications on the Linux
> > kernel VM. As there has been much controversy of late on this subject, it
> It was said that code is sufficient, you can read it and ask questions
> on lkml if you will find difficult to swallow parts. You may spot some
> bugs also, that will be very good! Linux kernel needs peer review!
I don't agree with this. If you don't have documentation, you
only know what the code does, not what it's supposed to do.
This means not only does it become harder to understand things,
it also becomes much harder to verify that the code is doing
the right thing.
> Writing docs wastes developer's time: they will write how they want VM to
> operate or how they think it operates (while some bug can make actual VM
> operate differently) instead of improving/debugging current VM code.
On the contrary. I have found that updating the documentation
of a function before fixing the code helps to keep me focussed
on letting this function do the exact right thing.
Working the other way around often leads to the "wait a moment,
shouldn't I catch this special case ??" thing and at times to
spagetti code.
Writing the documentation first makes it easier to realise that
some functionality doesn't belong in a function and needs to be
abstracted out, which I'm doing at a nice rate in the -rmap VM.
> Yes, it is not an easy path to VM doc. :-)
Just download the -rmap patch and start reading.
It's not _that_ hard ;)
cheers,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
On Thu, Jan 24, 2002 at 10:05:43AM -0200, Rik van Riel wrote:
> I made a paper about the old VM in the 2.4 kernels, with some
> overview of its shortcomings and what needs to be fixed.
And probably the closest thing to documentation for
the newer 2.4 VM is in some slides from Andrea..
ftp://ftp.suse.com/pub/people/andrea/talks/2001/pluto-dec-pub-0.tar.gz
Some bits may have changed a little since those slides were done,
(especially in -aa VM) but for the most part they make interesting
reading.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On 24 January 2002 01:36, [email protected] wrote:
> I am interested in reviewing the technical specifications on the Linux
> kernel VM. As there has been much controversy of late on this subject, it
> would be relevant to compare the concepts behind both the former VM and the
> new VM in order to obtain a better understanding of the issues. Is there a
> ?white paper? available on both the old and the new VM?s? Understandably,
> the VM is a work in progress; however, there should be a basic set of
> design goals and concepts from which future development will proceed. It
> would definitely be helpful to present them both as an aid to further
> analysis.
It was said that code is sufficient, you can read it and ask questions on
lkml if you will find difficult to swallow parts. You may spot some bugs
also, that will be very good! Linux kernel needs peer review!
Writing docs wastes developer's time: they will write how they want VM to
operate or how they think it operates (while some bug can make actual VM
operate differently) instead of improving/debugging current VM code.
After you got to understand how Linux VM works from source, feel free to
write docs.
Yes, it is not an easy path to VM doc. :-)
I must say I did not do it (yet?).
--
vda
Denis Vlasenko <[email protected]> writes:
> Writing docs wastes developer's time: they will write how they want VM to
> operate or how they think it operates (while some bug can make actual VM
> operate differently) instead of improving/debugging current VM code.
I don't want to judge, wether writing docs wastes developer's
time. But, when I first tried understanding file systems, it was of
tremendous help having docs like Documentation/filesystems/vfs.txt and
the like. I couldn't have done it without.
> After you got to understand how Linux VM works from source, feel free to
> write docs.
When you're that far, you are a developer and it will waste your time
writing docs ;-).
Regards, Olaf.
On 24 Jan 2002, Olaf Dietsche wrote:
> Denis Vlasenko <[email protected]> writes:
>
> > Writing docs wastes developer's time: they will write how they want VM to
> > operate or how they think it operates (while some bug can make actual VM
> > operate differently) instead of improving/debugging current VM code.
>
> I don't want to judge, wether writing docs wastes developer's
> time.
Not writing docs wastes other developers' time.
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
Rik van Riel writes:
> On 24 Jan 2002, Olaf Dietsche wrote:
> > Denis Vlasenko <[email protected]> writes:
> >
> > > Writing docs wastes developer's time: they will write how they want VM to
> > > operate or how they think it operates (while some bug can make actual VM
> > > operate differently) instead of improving/debugging current VM code.
> >
> > I don't want to judge, wether writing docs wastes developer's
> > time.
>
> Not writing docs wastes other developers' time.
Aka. being selfish and lazy.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On January 24, 2002 05:06 pm, Denis Vlasenko wrote:
> Writing docs wastes developer's time: they will write how they want VM to
> operate or how they think it operates (while some bug can make actual VM
> operate differently) instead of improving/debugging current VM code.
No you're wrong. Not writing docs wastes the time of other developers. It
sends the message 'my time is more important than yours'. In the case of
Linus, that may be true, but it's very definitely not true for any other core
developer.
It is the responsibility of each developer to prepare at least minimal - but
sufficient - documentation for the work they do. Others who specialize in
preparing documentation can then use that material as a starting point for
preparing clearer, more extensive documentation. But if core developers shirk
their responsibility in this area, we will continue to suffer from a chronic
shortage of good, current kernel documentation.
--
Daniel
> > I don't want to judge, wether writing docs wastes developer's
> > time.
>
> Not writing docs wastes other developers' time.
Writing about not writing docs wastes everybody's time.
Please excuse my lack of restraint. :-)
MikaL
> Writing about not writing docs wastes everybody's time.
For the record, I would love to see some proper documentation on the
current VM. While the code is indeed the ultimate reference, it does not
yield readily to peer review.
That said, I don't think much of the waterfall model. It tends to kill
the enthusiasm and slow projects down to a crawl. The thing is to write
the code, hone it until you're happy with it, and then document it. If
the code isn't ready to document, it's not ready for peer review. Prior
to that degree of readiness, too many brains plucking at the code just
slows things down. On the other hand, if you leave out the documentation
altogether you end up with developers arguing about who can't read whose
code, instead of doing something useful.
I seemed to touch the hearts of a surprising number of people with my
thoughtless little remark. No permanent heart ache, I hope. :)
MikaL