Re: Some ideas about new features of grub

[Vladimir 'phcoder' Serbinenko]

>> > Hard drives and CD-ROMs are usually large and would take a lot of space
>> > in memory that would need to remain allocated.  I think we need a strong
>> > case to start that effort.
>> >
>> Todays RAM is usually big enough. This feature would mainly be used to
>> boot install images and not normal OSes and install image + memory
>> needed for installer usually fits 1GiB. On the other hand small
>> laptops and netbook usualy have no CD. It would also be possible not
>> to store the image in RAM and read it directly from disk if grub's
>> drivers are left in memory one way or another.
>
> I think keeping the whole GRUB in memory for that purpose would be a
> major overkill.  I would probably create a file map on the disk (like,
> sectors 0-10 of the file are in sectors 1000-1010 of the disk etc)
blocklists are unreliable, we both know it even if in this case it may
be less grave. Additionally even if you use blocklists you still need
device driver and keeping in memory device driver or device+fs driver
isn't of much difference. I prefer a clean approach whixh would ensure
that if a driver works in grub it will also work while let to provide
services. That's why I proposed double kernel compilation
> and
> leave a simple interrupt handler that would emulate a BIOS disk by using
> that map.
>
> But I don't see it as priority.
>
Neither do I but I want to ensure if someone implements it it will be
in a clean way
>> > I'd rather see an effort to support CD-ROM and other ATAPI devices
>> > without disrupting BIOS access to the hard drives and floppies.
>> You can't have 2 disk drivers operation on same device without taking
>> some risk.
>
> Floppies are not the same device.  Yes, there is some risk accessing a
> CD-ROM while BIOS accesses a hard drive on the same controller.  But I
> think GRUB would never do it in parallel.
Even so, drive may have some persistent states and I see this as
potentially unreliable
> Floppies can be supported via int 13 even if the ATA module is in use.
> Or we can use int 40 to be extra safe.
>
Is int 40 a hardware interrupt? If so additional advantage of
implementing it would be coreboot support
>> >  We also
>> > need AHCI support.
>> >
>> Isn't it already the case?
>
> I don't see it.
>
I guess you need to test it with ata.mod - perhaps it works
> --
> Regards,
> Pavel Roskin
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git