Driver Development & Organization
d4rk...@gmail.com
I'm interested in this driver development phase, and even if I have no
experience yet in this context, I'm not a beginner in C or assembly so
I would like to give it a try (either develop a driver or help to
develop it)... The FAT driver is probably the simplest one but even at
this stage a bit of organization is needed.
First, as I'm new to this project, are there any assignments already
made for the drivers or other part of the OS? There are several
registered users on the site, i thought you were the single developer
until now, Andrew, but perhaps it's no longer the case?
I downloaded the last release to check the status of the project.
What I think is currently missing is a programming 'standard' (naming
convention, documentation, etc.) I see (Andrew) you started to use the
doxygen tags to generate the documentation, is it definitive or just a
test? And I think that a quick summary of the available tools
(debugging functions, the things working, the things that are buggy,
etc) would be welcome. For instance I've seen on the blog that the
paging module of the kernel is not quite stable, so is there some hacks
allowing to disable it while working on other things?
The second point is the driver model, clearly a lot of hardware driver
follow the same pattern and in particular as we are speaking of the
filesystems, we should have an interface for all the 'storage devices
drivers'. I've seen in 'fat.h' that the structure name is
'HdFsFatEntry' and I would say this is not a good idea, as this driver
will be used for a lot of storage devices, so why the prefix 'Hd'?(I
guess this was just a draft but I prefer to ask).
To sumup, 1/ what is the planning/organization if someone wants to
help? 2/ are the different interfaces (storage devices/fs) defined
already? Are there some RFC for AWOS somewhere? :)
Concerning IFS, if I correctly understood the concept, we somehow have
an abstraction 'struct FileSystem' which implements a set of primitives
(changeDirectory, openFile, etc.) and the O/S simply uses those generic
primitives instead of a direct call to the FS driver functions. Am I
right? In any case I agree to create a generic interface to access the
FS driver.
Thanks in advance for your answers.
--
d4rk
![Andrew Wilcox [maintainer]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjVTbeDZhCofdKmcACnEwKAx8R-yHjXpX89peUrcAs9mNSbD-3s=s40-c)
Andrew Wilcox [maintainer]
> I'm interested in this driver development phase, and even if I have no
> experience yet in this context, I'm not a beginner in C or assembly so
> I would like to give it a try (either develop a driver or help to
> develop it)... The FAT driver is probably the simplest one but even at
> this stage a bit of organization is needed.
> First, as I'm new to this project, are there any assignments already
> made for the drivers or other part of the OS?
No, no we just work on what we think of.
> There are several
> registered users on the site, i thought you were the single developer
> until now, Andrew, but perhaps it's no longer the case?
That's correct, there's a few more that aren't registered that are on
our Freenode IRC channel (orwell.freenode.net channel #AWOS). Yes I
really have a team now :)
> I downloaded the last release to check the status of the project.
> What I think is currently missing is a programming 'standard' (naming
> convention, documentation, etc.)
I tried fairly hard to have some form of naming convention. I was
going for NT-style, e.g. KiHardDiskDetect or KsMemory.
> I see (Andrew) you started to use the
> doxygen tags to generate the documentation, is it definitive or just a
> test?
It's definitive, I update it when the functions change, but I'm still
adding tags in a few place I miss as I come across them. I need to add
this to the Google Code project page, the doc site is
http://andrew.r.wilcox.googlepages.com/index.html .
> And I think that a quick summary of the available tools
> (debugging functions, the things working, the things that are buggy,
> etc) would be welcome.
Yeah I know, I have a release notes file somewhere on my hard drive but
it didn't really work well. For what I mean see
http://www.GeoCities.com/AWOSDev/kernels/004.txt or 005.txt.
> For instance I've seen on the blog that the
> paging module of the kernel is not quite stable, so is there some hacks
> allowing to disable it while working on other things?
The paging module is fixed and quite stable. There is just no paging
to disk yet, e.g. because there is no disk driver.
> The second point is the driver model, clearly a lot of hardware driver
> follow the same pattern and in particular as we are speaking of the
> filesystems, we should have an interface for all the 'storage devices
> drivers'. I've seen in 'fat.h' that the structure name is
> 'HdFsFatEntry' and I would say this is not a good idea, as this driver
> will be used for a lot of storage devices, so why the prefix 'Hd'?(I
> guess this was just a draft but I prefer to ask).
Yes it was just a draft. When I started work on the NTFS driver today
I noticed that, it is now FsFat, I'm going to be svn up'ing that in a
matter of minutes.
> To sumup, 1/ what is the planning/organization if someone wants to
> help?
No real planning or organization. And that's a reason I started this
list, so that we could work on that.
> 2/ are the different interfaces (storage devices/fs) defined
> already? Are there some RFC for AWOS somewhere? :)
Hehe no, no RFCs. I will be writing some extra Doxygen documentation
though, on Related Pages on that Doxygen link I gave before. As you
can see a beginning of a bug list and todo list is there.
> Concerning IFS, if I correctly understood the concept, we somehow have
> an abstraction 'struct FileSystem' which implements a set of primitives
> (changeDirectory, openFile, etc.) and the O/S simply uses those generic
> primitives instead of a direct call to the FS driver functions. Am I
> right? In any case I agree to create a generic interface to access the
> FS driver.
Well, kind of. To my understanding IFS is a lot like any other driver
on Windows, you export (like DLL function export) certain functions and
the OS uses them. So yes, in a way you are correct.
I have begun to read the book "Inside Windows NT Second Edition" and
recommend it highly. It gives a detailed look at what NT's kernel is
like. This helps us in two ways:
1. Understand how other kernel programmers accomplished the things we
are working on.
2. Since we will want to run Windows software, this tells us how the
Windows layer should work.
Another book I recommend highly is Upgrading & Repairing PCs by Scott
Mueller. It has a section on file systems that include basically a
struct definition of each of their bootsectors. FAT12/16, FAT32 and
NTFS. Plus a list of most of the partition table IDs and the MBR
(sector 0) layout. It also has information on just about every kind of
device there is. At over 1500 pages it has something for every driver
developer out there :)
So are you wanting to do the disk work with me? or something else? We
could probably make a Google Calendar or something with all the work we
want to do, or not, I'm not sure.
Well I guess I'll write some more stuff in Doxygen. I would appreciate
any suggestions on what I should write about.
Best regards,
Andrew
d4rk...@gmail.com
> > There are several
> > registered users on the site, i thought you were the single developer
> > until now, Andrew, but perhaps it's no longer the case?
> That's correct, there's a few more that aren't registered that are on
> our Freenode IRC channel (orwell.freenode.net channel #AWOS). Yes I
> really have a team now :)
That's impressive :) You gathered a lot of people in no time.
> > I downloaded the last release to check the status of the project.
> > What I think is currently missing is a programming 'standard' (naming
> > convention, documentation, etc.)
> I tried fairly hard to have some form of naming convention. I was
> going for NT-style, e.g. KiHardDiskDetect or KsMemory.
I was not clear enough, sorry, I have no doubt that you have a naming
convention, you're code is clean, what I was trying to say is that it
misses a file explaining it. I don't know the NT standard so the
prefixes are quite weird to me what 'Ki' and 'Ks' mean? K stands for
kernel I guess.
> > I see (Andrew) you started to use the
> > doxygen tags to generate the documentation, is it definitive or just a
> > test?
> It's definitive, I update it when the functions change, but I'm still
> adding tags in a few place I miss as I come across them. I need to add
> this to the Google Code project page, the doc site is
> http://andrew.r.wilcox.googlepages.com/index.html .
Ok. I didn't know these pages.
> > And I think that a quick summary of the available tools
> > (debugging functions, the things working, the things that are buggy,
> > etc) would be welcome.
> Yeah I know, I have a release notes file somewhere on my hard drive but
> it didn't really work well. For what I mean see
> http://www.GeoCities.com/AWOSDev/kernels/004.txt or 005.txt.
Yes something like that, this is useful to have quickly an overall idea
of the project status.
> > For instance I've seen on the blog that the
> > paging module of the kernel is not quite stable, so is there some hacks
> > allowing to disable it while working on other things?
> The paging module is fixed and quite stable. There is just no paging
> to disk yet, e.g. because there is no disk driver.
Ok, so the kernel is completely reliable (or should be)?
> > ...'HdFsFatEntry' and I would say this is not a good idea, as this driver
> > will be used for a lot of storage devices, so why the prefix 'Hd'?(I
> > guess this was just a draft but I prefer to ask).
> Yes it was just a draft. When I started work on the NTFS driver today
> I noticed that, it is now FsFat, I'm going to be svn up'ing that in a
> matter of minutes.
No problem.
> Another book I recommend highly is Upgrading & Repairing PCs by Scott
> Mueller. It has a section on file systems that include basically a
> struct definition of each of their bootsectors. FAT12/16, FAT32 and
> NTFS. Plus a list of most of the partition table IDs and the MBR
> (sector 0) layout. It also has information on just about every kind of
> device there is. At over 1500 pages it has something for every driver
> developer out there :)
That's interesting.
> So are you wanting to do the disk work with me?
Yes, one of the FS drivers. You already started the hd driver so I
won't interefere with that, we just need to agree on the interfaces.
But as I said it before, this is the first driver I will write so I've
no idea on any deadline. I'll take a look at the linux kernel sources
to estimate the work to be done.
--
d4rk
Andrew Wilcox [maintainer]
> I was not clear enough, sorry, I have no doubt that you have a naming
> convention, you're code is clean, what I was trying to say is that it
> misses a file explaining it. I don't know the NT standard so the
> prefixes are quite weird to me what 'Ki' and 'Ks' mean? K stands for
> kernel I guess.
Yeah, Ki means something else in NT but here it means Kernel Internal,
Ks is Kernel Startup. I'm tidying up the naming convention document
and then I will upload it.
> Ok. I didn't know these pages.
I know, I need to put it somewhere prominent.
> > http://www.GeoCities.com/AWOSDev/kernels/004.txt
> Yes something like that, this is useful to have quickly an overall idea
> of the project status.
Yes, but Build 9 isn't released yet, so I don't have a 009.txt yet. I
should probably include release notes with all the betas though, I know
that M$ did that with the W2K3 beta program.
> Ok, so the kernel is completely reliable (or should be)?
Yeah right. I said the paging is. kmalloc() has a bug that has been
plaguing me for about three months. I've had approximately 20 people
through various means look at the code and find nothing wrong. Also
putting my heap into a user mode program it works fine. I'll be making
a post soon.
> No problem.
Yeah I need to svn that now :)
> > Another book I recommend highly is Upgrading & Repairing PCs by Scott
> > Mueller.
> That's interesting.
Yeah, I have the 16th edition, you should be able to find that
somewhere cheap. It helps a lot, not just with OS/driver dev but also
with understanding what goes on inside the computer.
> > So are you wanting to do the disk work with me?
> Yes, one of the FS drivers. You already started the hd driver so I
> won't interefere with that, we just need to agree on the interfaces.
Right now the IDE driver works, save for the buggy kmalloc. So there
isn't a need to interfere because it's done :)
> But as I said it before, this is the first driver I will write so I've
> no idea on any deadline. I'll take a look at the linux kernel sources
> to estimate the work to be done.
No deadline, it gets done when it's done.
PLEASE NOTE, however, that the Linux code is GPLed and we are using the
original BSD license, which means that copying Linux code would
technically be illegal.
Best regards,
Andrew
d4rk...@gmail.com
> No deadline, it gets done when it's done.
That's a good point :)
>
> PLEASE NOTE, however, that the Linux code is GPLed and we are using the
> original BSD license, which means that copying Linux code would
> technically be illegal.
Then be relieved, I do not intend at all to copy anything :) Just
estimate the amount of work from a quick peek to the linux kernel
source (number of lines, etc.) for the concerned drivers.
Regards.
--
d4rk