Hi,
Ok, this reminds me of something I noticed using the grub shell.
When the grub shell modifies the MBR for the `hide' or `unhide'
command it does not issue a `BLKRRPART ioctl()', unlike fdisk
which does issue `BLKRRPART ioctl()' when, eg, only the partition
type is modified.
The `BLKRRPART ioctl()' should be issued by the grub shell in this
case, since the kernel's view of the partition tables may need to
be changed, and the kernel needs to be notified of this.
Now my $0.02US on raw disk access by the grub shell.
Almost everything that the grub shell needs to do can be
accomplished using normal user I/O system calls through the
filesystem. The grub shell is a very specialized program, if the
kernel provides sufficient facilities for the grub shell, then
even if there is duplicate functions in grub, and the elegance of
the grub shell concept is compromised, then so be it.
The remaining areas that cannot be accessed by normal user I/O
system calls are the grub shell writing to the remainder of the
first track after the MBR, eg, to install a stage 1.5 there, and
the grub shell writing to the PBB and maybe the remainder of the
same track to install, eg, a stage 1 in the PBB or a stage 1.5 in
the remainder of that track.
Unfortunately, I don't understand enough about the sematics of raw
I/O to make any suggestions for these remaining areas.
--
Jeff Sheinberg <[EMAIL PROTECTED]>
