Subject: Re: bsddisklabel and BLKRRPART
From: Andrea Arcangeli (email@example.com)
Date: Tue Oct 12 1999 - 18:33:53 PDT
On Wed, 13 Oct 1999 Andries.Brouwer@cwi.nl wrote:
>(In fact I fixed things slightly differently and released
>util-linux-2.9z some hours ago. Since it seems you actually
I seen your email in the same dialup connection I sent my one... (== too
>use bsd disklabels, perhaps you can verify that I did nothing
Could you show me your diff? (otherwise I'll have to download two
different ulti-linux and diff myself).
>[concerning your fix: (i) <sys/mount.h> does not exist on all
Yes. I know well I could use <linux/fs.h> but using glibc headers looked
more robust to me (I guess you used linux/fs.h as fdisk.c is just doing).
I don't like to depend on the kernel sources (at least when possible).
At first in my patch I used linux/fs.h. Then I thought to grep in
include/sys/*.h and I found the same define there and so I used it. I am
not an expert glibc user but if there is a define in sys/*.h I prefere it
against the kernel header as it will stay stable across kernel changes.
>systems, (ii) it also does a BLKRRPART when a new bootstrap
>is written, but it seems to me that in that case the disklabel
>stays the same and no BLKRRPART is required.])
As I don't know what means adding a bootstrap to a bsdlabel so I can't
I guess the bootstrap is adding some data not relevant to the partition
layout. In such case telling the kernel to reread the partition table
shouldn't matter and so it's not necessary.
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com
This archive was generated by hypermail 2a22 : Thu Nov 04 1999 - 16:56:58 PST