Re: Several ideas about grub2.

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 09/29/2010 12:42 AM, Dmitry Ilyin wrote:
> 1. Implementation of some progress bar for file reading
>
> Loading files from slow flash or network can sometimes take up to several 
> minutes (Linux initramfs could 
> be about 100Mb). And i'm thinking about some progress meter for file loading. 
> It could be print dot per 
> megabyte, percent or 34/76Mb style or like this |#######------------|.
> Looks like it should be build into grub_disk_read procedue in kern/disk.c or 
> grub_file_read in kern/file.c
> Maybe you could give me some hints about best way to do this.
>
>   
It's on TODO list. Exact code implementation isn't clear but keep in
mind that
a) (not very relevant but) some blocks may be reread multiple times
b) multiple files may be loaded in a row and progress of file X may be
irrelevant
c) It's ok to have it only when special function for reading is called
d) Don't update it too often, drawing takes time.
e) The part in core must be as small as possible. In fact the current
blocklist hook should be enough but it should be extended with special
values like GRUB_BLOCK_UNKNOWN or flag GRUB_BLOCK_NEVER_WRITE to mean
that FS is checksummed and saveenv should abort, and all curent users
must handle it (especially important for ZFS).
> 2. Basic text editor
>
> Is it possible to make basic text editor as grub2 module. I'm looking at "ed" 
> http://www.gnu.org/fun/jokes/ed.msg.html It will be very usefull to edit text 
> files (grub.cfg for example) 
> without booting os. Or there is no write support in filesystem drivers? Maybe 
> hex editor?
>
>   
It's OK to have an editor but it's not ok to save the resulting file.
Only save_env ever writes to filesystem since anything more than
environment (which requires a file reserved in advance and we just
overwrite its sector after checking that sector is indeed correct).
For any file editing it's better to boot into an OS, e.g. you can have
Linux+busybox-based initramfs for this purpose.
> 3. Installing on loop devices
>
> grub-install fails to work on loop devices. Partition detection doesn't work 
> on loop devices, but you can 
> use kpartx. For example we have /dev/loop0, using fdisk we create 2 
> partitions on this image, kpartx -a 
> /dev/loop0 will map partitions to /dev/mapper/loop0p1 and /dev/mapper/loop0p2 
> which you can format and 
> mount, but grub-install will fail (there is no bios drives for them?).
> No kernel partition detecion for loop devices is serious problem. Why kernel 
> cannot create /dev/loop0p1 
> and /dev/loop0p2 like with real hdds? FreeBSD's md's doesn't have this 
> problem and work like normal disks 
> with partitions. But this is not related to grub.
> What is the best way to fix installing on loop devices? Fixing grub-probe or 
> grub-install to not using 
> grub-probe when it cannot work and hardcode (hd0) prefix for loop devices?
>   
grub-probe must be fixed to handle loop device partitions.
> Using grub-mkimage and grub-setup manually works.
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

signature.asc
Description: OpenPGP digital signature