> By author: Andries.Brouwer@cwi.nl
> In newsgroup: linux.dev.kernel
> >
> >
> > > I should have been more verbose... I was writing that after using the
> > > "hda=c,h,s" kernel parameter to get around it. Just wanted to mention
> > > that there should be an option to do that in a running system. I don't
> > > like rebooting because of something like drive geometry... :)
> >
> > OK - reasonable enough.
> > It is easy to add some ioctl that does what you want.
> > On the other hand, there are not so many people that want to go
> > from a disk with to a disk without Disk Manager without rebooting.
> >
> > [And even if the ioctl is there, who will use it?
> > Hmm. Of course the new blockdev utility.
> > I suppose I'll add it sooner or later.]
> >
>
> I would like to concur with this. Part of the problem with Disk
> Manager et al is that they modify /dev/hda, which means that if the
> Disk Manager signature is detected, there is no way to access the
> whole disk as "random bulk storage"... including to wipe out Disk Manager.
>
> I would like to at least be able to:
>
> really-use-whole-disk /dev/hda
> dd if=/dev/zero of=/dev/hda bs=1024 count=1
> fdisk /dev/hda
> # Create partitions
> sync
> reboot
>
> ... all automatically.
Yes - I entirely agree. However, I just looked at the code and decided
not to submit a patch today. Maybe some other time.
The desired result can be achieved with a one-line patch:
in ide-disk.c add in idedisk_add_settings() a line
ide_add_setting(drive, "disk_manager_offset", SETTING_RW,
-1, -1, TYPE_BYTE, 0, 1, 1, 63, &drive->sect0, NULL);
say after the line for bios_sect. This will achieve that
cat disk_manager_offset:0 > /proc/ide/ide0/hda/settings
is equivalent to your
really-use-whole-disk /dev/hda
above. (Perhaps one would do
blockdev --flushbufs /dev/hda
before, and
blockdev --rereadpt /dev/hda
afterwards.)
However, I am a bit worried about submitting this 1-liner.
It would suffice for an experienced user, who understands
what is happening, but innocent lusers would see a very
interesting disk behaviour if the buffer cache was nonempty
and suddenly all block numbers changed by 63.
So, perhaps one wants to do fsync_dev() and invalidate_buffers()
before making this change, and we need a version of ide_revalidate_disk()
that does not do the resetup_one_device() immediately, but first
after the offset has been changed.
Too much honour for so very minor a problem.
But if Linus wants the patch (either one that is as small as possible,
but perhaps a bit ugly, or one that is as nice as possible, but perhaps
involving larger restructuring, avoiding some MKDEV calls in the ide code)
I can construct and submit it.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/