grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: My Summer of Code Project


From: Marco Gerards
Subject: Re: My Summer of Code Project
Date: Wed, 25 Apr 2007 15:01:41 +0200
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

"Alex Roman" <address@hidden> writes:

Hi Alex,

Please don't top quote, it is confusing ;-).

> Interesting piece of code... Yet another example of showing how to
> implement an ATA/IDE controller driver :)

Yeah.

btw, do you know http://www.osdever.net?

If you are looking for even more information, I could have a look at
which books about this subject I can recommend.

> Right now I'm pondering whether it is worth implementing a BIOS calls
> CDROM boot support, or whether I should just go right ahead and do it
> all with the ATA controller.

Both are important!  Really...

You should know GRUB 2 is designed to be portable and runs on lots of
different systems.

When the firmware gives access to the CDROM drive, this is usually a
nice feature to have.  One thing is that you have support for it, even
if it is SCSI (which you won't implement) or something else which is
terribly obscure :-).

Another nice reason you want this is that usually the firmware tells
you which drive you booted from.  For example, when you boot from a
CDROM drive it is easy to figure out which drive to load all files
from.  Think of livecds, etc.

Actually, an IDE driver is a terrible thing to have.  But it is
required for broken systems like the PC.  Some BIOSes do not have
CDROM support.  Other don't give you access to the CDROM drive when
you do not use it for booting.

> I'm not sure how IDE controllers work on PPC, since I've unfortunately
> never used the architecture...

If you make sure you keep endianess in mind, you usually will be doing
the right thing.  Besides that, on the PPC all IO is memory mapped.
You can have a look at linux to see how it deals with IO access.

> Technically, if the ATA/IDE driver is there, implementing the ATAPI
> command set to "talk" to the CDROM and interpreting the El-Torito spec
> shouldn't be that hard.

Yeah :)

> If CD-ROM drives are ATAPI on all platforms (where they use ATA), and
> the ATA code is there, the ATAPI and El Torito layer should stay
> cross-platform. The interesting bit will be making it so that
> "plugging in" a SCSI driver will require the least amount of code
> change.

El Torito is PC only, no?

> Anyways, I'm kind of rambling for now... Until the official "code
> start" day I'll do some more reading and investigating how it would be
> best to tie the code into GRUB2 to give the most elegant solution.

One good way to start is by just fixing random things in GRUB 2.  Play
with grub-emu, make a floppy image with GRUB 2 on it and boot it from
qemu.  Setup a good development environment (talking about this is
perhaps a smart thing to do, if you lack the experience).

For some other summer of code projects (like ffmpeg), the students we
required to send in patched before they were qualified.  IOW: you
couldn't be accepted, unless you sent in patches that were good enough
to make it into SVN.  By doing this they showed they are capable
enough to work on the project.  But besides that, and that is what I
am trying to say, is that it usually helps if you poke around a bit
and play with the code, you don't even have to do something useful.
And ask lots and lots of questions :-)

--
Marco





reply via email to

[Prev in Thread] Current Thread [Next in Thread]