"Alex Roman" <[EMAIL PROTECTED]> 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel