man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

[leon zadorin]

Man page for mount_vnd states:
"
The `c' partition of a vnd image should not be used.  When a superblock
     becomes damaged, fsck_ffs(8) needs information contained in the disklabel
     to determine the location of alternate superblocks.  This information is
     not available when directly using the `c' partition, so checking the file
     system image will fail.
"

Also, the man page for newfs states:
"
Before running newfs or mount_mfs, the disk must be labeled using
     disklabel(8).  newfs builds a file system on the specified special de-
     vice, basing its defaults on the information in the disk label.
"

But... the man 5 disklabel states:
"
Note that when a disk has no real BSD disklabel the kernel creates a de-
     fault label so that the disk can be used.
"

And indeed, it would appear (or may be my brain is getting sleepy)
that, running newfs on a device (such as svnd0c or vnd0c) which has no
disklabel installed explicitly does work ok...
... now --  if, as man page for mount_vnd states, fsck_ffs needs
disklabel info when superblock is damaged -- why would it have any
trouble getting the default label that kernel creates for the "disk"
automatically as per man 5 disklabel quote above (the very same info,
I presume that newfs uses when initializing the fs initially on an
image with no explicit label)?

For example, wrt alternate superblock issues during fskc, the man page
for newfs says:
"
     -S sector-size
                 The size of a sector in bytes (almost never anything but
                 512).  Changing this is useful only when using newfs to build
                 a file system whose raw image will eventually be used on a
                 different type of disk than the one on which it is initially
                 created (for example on a write-once disk).  Note that chang-
                 ing this from its default will make it impossible for fsck(8)
                 to find the alternate superblocks if the standard superblock
                 is lost.
"

Now, if the default disklabel (created by kernel, on the fly so to
speak) provides info for the sector size (which is used by newfs
during initializing, and by fsck when checking/restoring/fixing, the
fs) then why would it still be bad to use the "c" partition of
svnd/vnd?

Kind regards
Leon.

[Kenneth R Westerback]

On Sun, Jul 26, 2009 at 04:44:45AM +1100, leon zadorin wrote:

> Man page for mount_vnd states:
> "
> The `c' partition of a vnd image should not be used.  When a superblock
>      becomes damaged, fsck_ffs(8) needs information contained in the disklabel
>      to determine the location of alternate superblocks.  This information is
>      not available when directly using the `c' partition, so checking the file
>      system image will fail.
> "
>
> Also, the man page for newfs states:
> "
> Before running newfs or mount_mfs, the disk must be labeled using
>      disklabel(8).  newfs builds a file system on the specified special de-
>      vice, basing its defaults on the information in the disk label.
> "
>
> But... the man 5 disklabel states:
> "
> Note that when a disk has no real BSD disklabel the kernel creates a de-
>      fault label so that the disk can be used.
> "
>
> And indeed, it would appear (or may be my brain is getting sleepy)
> that, running newfs on a device (such as svnd0c or vnd0c) which has no
> disklabel installed explicitly does work ok...
> ... now --  if, as man page for mount_vnd states, fsck_ffs needs
> disklabel info when superblock is damaged -- why would it have any
> trouble getting the default label that kernel creates for the "disk"
> automatically as per man 5 disklabel quote above (the very same info,
> I presume that newfs uses when initializing the fs initially on an
> image with no explicit label)?
>
> For example, wrt alternate superblock issues during fskc, the man page
> for newfs says:
> "
>      -S sector-size
>                  The size of a sector in bytes (almost never anything but
>                  512).  Changing this is useful only when using newfs to build
>                  a file system whose raw image will eventually be used on a
>                  different type of disk than the one on which it is initially
>                  created (for example on a write-once disk).  Note that chang-
>                  ing this from its default will make it impossible for fsck(8)
>                  to find the alternate superblocks if the standard superblock
>                  is lost.
> "
>
> Now, if the default disklabel (created by kernel, on the fly so to
> speak) provides info for the sector size (which is used by newfs
> during initializing, and by fsck when checking/restoring/fixing, the
> fs) then why would it still be bad to use the "c" partition of
> svnd/vnd?
>
> Kind regards
> Leon.

'c' is a special partition that the kernel freely changes as the
mood hits it. A slight exaggeration. Never use 'c' for anything
other than reading/writing raw data.

.... Ken

[leon zadorin]

On 7/27/09, Kenneth R Westerback <kwesterback@...> wrote:

> On Sun, Jul 26, 2009 at 04:44:45AM +1100, leon zadorin wrote:
>> Man page for mount_vnd states:
>> "
>> The `c' partition of a vnd image should not be used.  When a superblock
>>      becomes damaged, fsck_ffs(8) needs information contained in the
>> disklabel
>>      to determine the location of alternate superblocks.  This information
>> is
>>      not available when directly using the `c' partition, so checking the
>> file
>>      system image will fail.
>> "
>>
>> Also, the man page for newfs states:
>> "
>> Before running newfs or mount_mfs, the disk must be labeled using
>>      disklabel(8).  newfs builds a file system on the specified special
>> de-
>>      vice, basing its defaults on the information in the disk label.
>> "
>>
>> But... the man 5 disklabel states:
>> "
>> Note that when a disk has no real BSD disklabel the kernel creates a de-
>>      fault label so that the disk can be used.
>> "
>>
>> And indeed, it would appear (or may be my brain is getting sleepy)
>> that, running newfs on a device (such as svnd0c or vnd0c) which has no
>> disklabel installed explicitly does work ok...
>> ... now --  if, as man page for mount_vnd states, fsck_ffs needs
>> disklabel info when superblock is damaged -- why would it have any
>> trouble getting the default label that kernel creates for the "disk"
>> automatically as per man 5 disklabel quote above (the very same info,
>> I presume that newfs uses when initializing the fs initially on an
>> image with no explicit label)?
>>
>> For example, wrt alternate superblock issues during fskc, the man page
>> for newfs says:
>> "
>>      -S sector-size
>>                  The size of a sector in bytes (almost never anything but
>>                  512).  Changing this is useful only when using newfs to
>> build
>>                  a file system whose raw image will eventually be used on
>> a
>>                  different type of disk than the one on which it is
>> initially
>>                  created (for example on a write-once disk).  Note that
>> chang-
>>                  ing this from its default will make it impossible for
>> fsck(8)
>>                  to find the alternate superblocks if the standard
>> superblock
>>                  is lost.
>> "
>>
>> Now, if the default disklabel (created by kernel, on the fly so to
>> speak) provides info for the sector size (which is used by newfs
>> during initializing, and by fsck when checking/restoring/fixing, the
>> fs) then why would it still be bad to use the "c" partition of
>> svnd/vnd?
>>
>> Kind regards
>> Leon.
>
> 'c' is a special partition that the kernel freely changes as the
> mood hits it. A slight exaggeration.

I'd say. Anywhere does it say this? My understanding was that 'c'
partition depicts the entire device. If this is correct, than it's not
even close to describing it as 'freely changing' it's semantics as per
kernel's mood. Artistic perhaps, but precise... not.

I don't mind not using 'c' partition for any explicit filesystems, but
I don't want to do so on some ritualistic, unsupported-by-explanations
'fear' but rather through explicit understanding as to why, albeit
customised, examples would not work (i.e. kernel-generated default
disklabel and only 1 ffs on disk image as per previous post of mine).

leon.

[Kenneth R Westerback]

On Mon, Jul 27, 2009 at 11:11:21AM +1000, leon zadorin wrote:

> On 7/27/09, Kenneth R Westerback <kwesterback@...> wrote:
> > On Sun, Jul 26, 2009 at 04:44:45AM +1100, leon zadorin wrote:
> >> Man page for mount_vnd states:
> >> "
> >> The `c' partition of a vnd image should not be used.  When a superblock
> >>      becomes damaged, fsck_ffs(8) needs information contained in the
> >> disklabel
> >>      to determine the location of alternate superblocks.  This information
> >> is
> >>      not available when directly using the `c' partition, so checking the
> >> file
> >>      system image will fail.
> >> "
> >>
> >> Also, the man page for newfs states:
> >> "
> >> Before running newfs or mount_mfs, the disk must be labeled using
> >>      disklabel(8).  newfs builds a file system on the specified special
> >> de-
> >>      vice, basing its defaults on the information in the disk label.
> >> "
> >>
> >> But... the man 5 disklabel states:
> >> "
> >> Note that when a disk has no real BSD disklabel the kernel creates a de-
> >>      fault label so that the disk can be used.
> >> "
> >>
> >> And indeed, it would appear (or may be my brain is getting sleepy)
> >> that, running newfs on a device (such as svnd0c or vnd0c) which has no
> >> disklabel installed explicitly does work ok...
> >> ... now --  if, as man page for mount_vnd states, fsck_ffs needs
> >> disklabel info when superblock is damaged -- why would it have any
> >> trouble getting the default label that kernel creates for the "disk"
> >> automatically as per man 5 disklabel quote above (the very same info,
> >> I presume that newfs uses when initializing the fs initially on an
> >> image with no explicit label)?
> >>
> >> For example, wrt alternate superblock issues during fskc, the man page
> >> for newfs says:
> >> "
> >>      -S sector-size
> >>                  The size of a sector in bytes (almost never anything but
> >>                  512).  Changing this is useful only when using newfs to
> >> build
> >>                  a file system whose raw image will eventually be used on
> >> a
> >>                  different type of disk than the one on which it is
> >> initially
> >>                  created (for example on a write-once disk).  Note that
> >> chang-
> >>                  ing this from its default will make it impossible for
> >> fsck(8)
> >>                  to find the alternate superblocks if the standard
> >> superblock
> >>                  is lost.
> >> "
> >>
> >> Now, if the default disklabel (created by kernel, on the fly so to
> >> speak) provides info for the sector size (which is used by newfs
> >> during initializing, and by fsck when checking/restoring/fixing, the
> >> fs) then why would it still be bad to use the "c" partition of
> >> svnd/vnd?
> >>
> >> Kind regards
> >> Leon.
> >
> > 'c' is a special partition that the kernel freely changes as the
> > mood hits it. A slight exaggeration.
>
> I'd say. Anywhere does it say this? My understanding was that 'c'
> partition depicts the entire device. If this is correct, than it's not
> even close to describing it as 'freely changing' it's semantics as per
> kernel's mood. Artistic perhaps, but precise... not.
>
> I don't mind not using 'c' partition for any explicit filesystems, but
> I don't want to do so on some ritualistic, unsupported-by-explanations
> 'fear' but rather through explicit understanding as to why, albeit
> customised, examples would not work (i.e. kernel-generated default
> disklabel and only 1 ffs on disk image as per previous post of mine).
>
> leon.

2nd paragraph of disklabel(8):

disklabel supports 15 configurable partitions, `a' through `p', excluding
`c'.  The `c' partition describes the entire physical disk, is automati-
cally created by the kernel, and cannot be modified or deleted by
disklabel.

Feel free to use 'c' for anything you want. Just don't complain, or expect
short shrift when you do, if it blows up later on because the kernel is
making free use of it by arbitrarily changing its limits to reflect a
new concept of 'whole disk'.

.... Ken

[leon zadorin]

On 7/27/09, Kenneth R Westerback <kwesterback@...> wrote:

> On Mon, Jul 27, 2009 at 11:11:21AM +1000, leon zadorin wrote:
>> On 7/27/09, Kenneth R Westerback <kwesterback@...> wrote:
>> > On Sun, Jul 26, 2009 at 04:44:45AM +1100, leon zadorin wrote:
>> >> Man page for mount_vnd states:
>> >> "
>> >> The `c' partition of a vnd image should not be used.  When a superblock
>> >>      becomes damaged, fsck_ffs(8) needs information contained in the
>> >> disklabel
>> >>      to determine the location of alternate superblocks.  This
>> >> information
>> >> is
>> >>      not available when directly using the `c' partition, so checking
>> >> the
>> >> file
>> >>      system image will fail.
>> >> "
>> >>
>> >> Also, the man page for newfs states:
>> >> "
>> >> Before running newfs or mount_mfs, the disk must be labeled using
>> >>      disklabel(8).  newfs builds a file system on the specified special
>> >> de-
>> >>      vice, basing its defaults on the information in the disk label.
>> >> "
>> >>
>> >> But... the man 5 disklabel states:
>> >> "
>> >> Note that when a disk has no real BSD disklabel the kernel creates a
>> >> de-
>> >>      fault label so that the disk can be used.
>> >> "
>> >>
>> >> And indeed, it would appear (or may be my brain is getting sleepy)
>> >> that, running newfs on a device (such as svnd0c or vnd0c) which has no
>> >> disklabel installed explicitly does work ok...
>> >> ... now --  if, as man page for mount_vnd states, fsck_ffs needs
>> >> disklabel info when superblock is damaged -- why would it have any
>> >> trouble getting the default label that kernel creates for the "disk"
>> >> automatically as per man 5 disklabel quote above (the very same info,
>> >> I presume that newfs uses when initializing the fs initially on an
>> >> image with no explicit label)?
>> >>
>> >> For example, wrt alternate superblock issues during fskc, the man page
>> >> for newfs says:
>> >> "
>> >>      -S sector-size
>> >>                  The size of a sector in bytes (almost never anything
>> >> but
>> >>                  512).  Changing this is useful only when using newfs
>> >> to
>> >> build
>> >>                  a file system whose raw image will eventually be used
>> >> on
>> >> a
>> >>                  different type of disk than the one on which it is
>> >> initially
>> >>                  created (for example on a write-once disk).  Note that
>> >> chang-
>> >>                  ing this from its default will make it impossible for
>> >> fsck(8)
>> >>                  to find the alternate superblocks if the standard
>> >> superblock
>> >>                  is lost.
>> >> "
>> >>
>> >> Now, if the default disklabel (created by kernel, on the fly so to
>> >> speak) provides info for the sector size (which is used by newfs
>> >> during initializing, and by fsck when checking/restoring/fixing, the
>> >> fs) then why would it still be bad to use the "c" partition of
>> >> svnd/vnd?
>> >>
>> >> Kind regards
>> >> Leon.
>> >
>> > 'c' is a special partition that the kernel freely changes as the
>> > mood hits it. A slight exaggeration.
>>
>> I'd say. Anywhere does it say this? My understanding was that 'c'
>> partition depicts the entire device. If this is correct, than it's not
>> even close to describing it as 'freely changing' it's semantics as per
>> kernel's mood. Artistic perhaps, but precise... not.
>>
>> I don't mind not using 'c' partition for any explicit filesystems, but
>> I don't want to do so on some ritualistic, unsupported-by-explanations
>> 'fear' but rather through explicit understanding as to why, albeit
>> customised, examples would not work (i.e. kernel-generated default
>> disklabel and only 1 ffs on disk image as per previous post of mine).
>>
>> leon.
>
> 2nd paragraph of disklabel(8):
>
> disklabel supports 15 configurable partitions, `a' through `p', excluding
> `c'.  The `c' partition describes the entire physical disk, is automati-
> cally created by the kernel, and cannot be modified or deleted by
> disklabel.

To me it sounds precise-enough (i.e. 'describes the *entire*
*physical* disk' vs "special partition that the kernel freely changes
as the mood hits it" is not a slight difference in description).

> Feel free to use 'c' for anything you want. Just don't complain, or expect
> short shrift when you do, if it blows up later on because the kernel is

:-) I don't recall expressing any complaints or having any short
shrift expectations. In fact, all I am doing is trying to understand
the internals/actual behavior model in a more intimate way.

> making free use of it by arbitrarily changing its limits to reflect a
> new concept of 'whole disk'.

Sounds a little nonsensical to me.

1) for example, it would make no sense to 'shrink' the size of
conceptual 'whole disk' (esp. if such represents the entire *physical*
disk as per man pages) to be less than other partitions -- so
'*arbitrary* changing its [disk's] limits' is an over-generalization
in my opinion.

2) w.r.t. forward-compatibility, one cannot make any suppositions for
system's (kernel or userland) behavior in future versions/releases for
practically anything (e.g. the key-generating hash in vnconfig may not
be guaranteed to forever remain the same; the format of system calls
may change/evolve, disklabel format may/may-not change, sector-size
may become editable, etc.)... and I am certainly not looking this far
into the future (i.e. namely and most-likely I am considering the
behavior wrt current kernel w/o such being upgraded continuously). In
other words, I am perfectly happy to accept the failed 'mount/fsck'
attempts when/if differently-behaving kernel is being deployed.

leon.

[Theo de Raadt]

> I'd say. Anywhere does it say this? My understanding was that 'c'
> partition depicts the entire device. If this is correct, than it's not
> even close to describing it as 'freely changing' it's semantics as per
> kernel's mood. Artistic perhaps, but precise... not.

hey, feel free to believe whatever you want.

> I don't mind not using 'c' partition for any explicit filesystems, but
> I don't want to do so on some ritualistic, unsupported-by-explanations
> 'fear' but rather through explicit understanding as to why, albeit
> customised, examples would not work (i.e. kernel-generated default
> disklabel and only 1 ffs on disk image as per previous post of mine).

yeah, looking at the code is ritualistic

Guess we should stop making it available.

[Theo de Raadt]

> Sounds a little nonsensical to me.
>
> 1) for example, it would make no sense to 'shrink' the size of
> conceptual 'whole disk' (esp. if such represents the entire *physical*
> disk as per man pages) to be less than other partitions -- so
> '*arbitrary* changing its [disk's] limits' is an over-generalization
> in my opinion.
>
> 2) w.r.t. forward-compatibility, one cannot make any suppositions for
> system's (kernel or userland) behavior in future versions/releases for
> practically anything (e.g. the key-generating hash in vnconfig may not
> be guaranteed to forever remain the same; the format of system calls
> may change/evolve, disklabel format may/may-not change, sector-size
> may become editable, etc.)... and I am certainly not looking this far
> into the future (i.e. namely and most-likely I am considering the
> behavior wrt current kernel w/o such being upgraded continuously). In
> other words, I am perfectly happy to accept the failed 'mount/fsck'
> attempts when/if differently-behaving kernel is being deployed.

The source code defines the behaviour.

Your words don't.

[leon zadorin]

On 7/27/09, Theo de Raadt <deraadt@...> wrote:
>> I'd say. Anywhere does it say this? My understanding was that 'c'
>> partition depicts the entire device. If this is correct, than it's not
>> even close to describing it as 'freely changing' it's semantics as per
>> kernel's mood. Artistic perhaps, but precise... not.
>
> hey, feel free to believe whatever you want.

it's not about the belief, it's about the understanding.


>
>> I don't mind not using 'c' partition for any explicit filesystems, but
>> I don't want to do so on some ritualistic, unsupported-by-explanations
>> 'fear' but rather through explicit understanding as to why, albeit
>> customised, examples would not work (i.e. kernel-generated default
>> disklabel and only 1 ffs on disk image as per previous post of mine).
>
> yeah, looking at the code is ritualistic

my comments were *not* wrt source code, they were wrt to the
aforementioned *artistic* definition/explanation of c's partition and
it's view wrt kernel's default disklabel creation.

> Guess we should stop making it available.

I guess not :-)

[leon zadorin]

On 7/27/09, Theo de Raadt <deraadt@...> wrote:

>> Sounds a little nonsensical to me.
>>
>> 1) for example, it would make no sense to 'shrink' the size of
>> conceptual 'whole disk' (esp. if such represents the entire *physical*
>> disk as per man pages) to be less than other partitions -- so
>> '*arbitrary* changing its [disk's] limits' is an over-generalization
>> in my opinion.
>>
>> 2) w.r.t. forward-compatibility, one cannot make any suppositions for
>> system's (kernel or userland) behavior in future versions/releases for
>> practically anything (e.g. the key-generating hash in vnconfig may not
>> be guaranteed to forever remain the same; the format of system calls
>> may change/evolve, disklabel format may/may-not change, sector-size
>> may become editable, etc.)... and I am certainly not looking this far
>> into the future (i.e. namely and most-likely I am considering the
>> behavior wrt current kernel w/o such being upgraded continuously). In
>> other words, I am perfectly happy to accept the failed 'mount/fsck'
>> attempts when/if differently-behaving kernel is being deployed.
>
> The source code defines the behaviour.
>
> Your words don't.
>

Neither do yours :-) Although, some would also say that source code is
not always *defining*, but rather *implementing* the behavior (which
is standardized perhaps elsewhere)... but anyway -- potato, potato :-)

[Theo de Raadt]

> On 7/27/09, Theo de Raadt <deraadt@...> wrote:
> >> Sounds a little nonsensical to me.
> >>
> >> 1) for example, it would make no sense to 'shrink' the size of
> >> conceptual 'whole disk' (esp. if such represents the entire *physical*
> >> disk as per man pages) to be less than other partitions -- so
> >> '*arbitrary* changing its [disk's] limits' is an over-generalization
> >> in my opinion.
> >>
> >> 2) w.r.t. forward-compatibility, one cannot make any suppositions for
> >> system's (kernel or userland) behavior in future versions/releases for
> >> practically anything (e.g. the key-generating hash in vnconfig may not
> >> be guaranteed to forever remain the same; the format of system calls
> >> may change/evolve, disklabel format may/may-not change, sector-size
> >> may become editable, etc.)... and I am certainly not looking this far
> >> into the future (i.e. namely and most-likely I am considering the
> >> behavior wrt current kernel w/o such being upgraded continuously). In
> >> other words, I am perfectly happy to accept the failed 'mount/fsck'
> >> attempts when/if differently-behaving kernel is being deployed.
> >
> > The source code defines the behaviour.
> >
> > Your words don't.
> >
>
> Neither do yours :-) Although, some would also say that source code is
> not always *defining*, but rather *implementing* the behavior (which
> is standardized perhaps elsewhere)... but anyway -- potato, potato :-)

Oh cut the crap.

krw and I have a view how it should work, and we code it.
Then the code is the behaviour.

Perhaps we made mistakes.  Perhaps they'll be changed.

But you are just spouting bullshit.

[leon zadorin]

On 7/27/09, Theo de Raadt <deraadt@...> wrote:

>> On 7/27/09, Theo de Raadt <deraadt@...> wrote:
>> >> Sounds a little nonsensical to me.
>> >>
>> >> 1) for example, it would make no sense to 'shrink' the size of
>> >> conceptual 'whole disk' (esp. if such represents the entire *physical*
>> >> disk as per man pages) to be less than other partitions -- so
>> >> '*arbitrary* changing its [disk's] limits' is an over-generalization
>> >> in my opinion.
>> >>
>> >> 2) w.r.t. forward-compatibility, one cannot make any suppositions for
>> >> system's (kernel or userland) behavior in future versions/releases for
>> >> practically anything (e.g. the key-generating hash in vnconfig may not
>> >> be guaranteed to forever remain the same; the format of system calls
>> >> may change/evolve, disklabel format may/may-not change, sector-size
>> >> may become editable, etc.)... and I am certainly not looking this far
>> >> into the future (i.e. namely and most-likely I am considering the
>> >> behavior wrt current kernel w/o such being upgraded continuously). In
>> >> other words, I am perfectly happy to accept the failed 'mount/fsck'
>> >> attempts when/if differently-behaving kernel is being deployed.
>> >
>> > The source code defines the behaviour.
>> >
>> > Your words don't.
>> >
>>
>> Neither do yours :-) Although, some would also say that source code is
>> not always *defining*, but rather *implementing* the behavior (which
>> is standardized perhaps elsewhere)... but anyway -- potato, potato :-)
>
> Oh cut the crap.
>
> krw and I have a view how it should work, and we code it.
> Then the code is the behaviour.
>
> Perhaps we made mistakes.  Perhaps they'll be changed.
>
> But you are just spouting bullshit.
>

:-) :-) :-) relax, take a pill -- no need to get emotional.

besides I don't think we are seeing things that much differently. I
didn't say you were making mistakes, but if you make krap-inviting
statements like "the source code *defines* the behavior" then expect
the likewise, albeit not-that-serious, replies.

Besides, the code may well be acting like implementation and
definition in one place, so no need to take such a heated bait to my
light replies. I'll stop now :-)


chill -- I don't mean to get a flame-war started, peace dude :-)

[Theo de Raadt]

> On 7/27/09, Theo de Raadt <deraadt@...> wrote:
> >> On 7/27/09, Theo de Raadt <deraadt@...> wrote:
> >> >> Sounds a little nonsensical to me.
> >> >>
> >> >> 1) for example, it would make no sense to 'shrink' the size of
> >> >> conceptual 'whole disk' (esp. if such represents the entire *physical*
> >> >> disk as per man pages) to be less than other partitions -- so
> >> >> '*arbitrary* changing its [disk's] limits' is an over-generalization
> >> >> in my opinion.
> >> >>
> >> >> 2) w.r.t. forward-compatibility, one cannot make any suppositions for
> >> >> system's (kernel or userland) behavior in future versions/releases for
> >> >> practically anything (e.g. the key-generating hash in vnconfig may not
> >> >> be guaranteed to forever remain the same; the format of system calls
> >> >> may change/evolve, disklabel format may/may-not change, sector-size
> >> >> may become editable, etc.)... and I am certainly not looking this far
> >> >> into the future (i.e. namely and most-likely I am considering the
> >> >> behavior wrt current kernel w/o such being upgraded continuously). In
> >> >> other words, I am perfectly happy to accept the failed 'mount/fsck'
> >> >> attempts when/if differently-behaving kernel is being deployed.
> >> >
> >> > The source code defines the behaviour.
> >> >
> >> > Your words don't.
> >> >
> >>
> >> Neither do yours :-) Although, some would also say that source code is
> >> not always *defining*, but rather *implementing* the behavior (which
> >> is standardized perhaps elsewhere)... but anyway -- potato, potato :-)
> >
> > Oh cut the crap.
> >
> > krw and I have a view how it should work, and we code it.
> > Then the code is the behaviour.
> >
> > Perhaps we made mistakes.  Perhaps they'll be changed.
> >
> > But you are just spouting bullshit.
> >
>
> :-) :-) :-) relax, take a pill -- no need to get emotional.
>
> besides I don't think we are seeing things that much differently. I
> didn't say you were making mistakes, but if you make krap-inviting
> statements like "the source code *defines* the behavior" then expect
> the likewise, albeit not-that-serious, replies.
>
> Besides, the code may well be acting like implementation and
> definition in one place, so no need to take such a heated bait to my
> light replies. I'll stop now :-)
>
>
> chill -- I don't mean to get a flame-war started, peace dude :-)

I don't know who you are, but you do nothing.  What do you do?

I don't see your name on any the source code.

The source code _does_ define the behaviour.  Exactly.  Perhaps the
source code is wrong, but it *EXACTLY DEFINES THE BEHAVIOUR*.

So you shut up, loser.  Just go away.

[Marco Peereboom]

> :-) :-) :-) relax, take a pill -- no need to get emotional.
>
> besides I don't think we are seeing things that much differently. I
> didn't say you were making mistakes, but if you make krap-inviting
> statements like "the source code *defines* the behavior" then expect
> the likewise, albeit not-that-serious, replies.
>
> Besides, the code may well be acting like implementation and
> definition in one place, so no need to take such a heated bait to my
> light replies. I'll stop now :-)
>
>
> chill -- I don't mean to get a flame-war started, peace dude :-)

Wow it is sunday night and you have used up all the manager-buzzword
speak for an entire month.  What's next we have to go do some Agile
programming while implementing Extreme Programming ideas for UML
development that then becomes XML which we then can peruse for automated
testing because humans should not test?

If I am not VP material now I don't know what will...

[leon zadorin]

On 7/27/09, Theo de Raadt <deraadt@...> wrote:

>> On 7/27/09, Theo de Raadt <deraadt@...> wrote:
>> >> On 7/27/09, Theo de Raadt <deraadt@...> wrote:
>> >> >> Sounds a little nonsensical to me.
>> >> >>
>> >> >> 1) for example, it would make no sense to 'shrink' the size of
>> >> >> conceptual 'whole disk' (esp. if such represents the entire
>> >> >> *physical*
>> >> >> disk as per man pages) to be less than other partitions -- so
>> >> >> '*arbitrary* changing its [disk's] limits' is an over-generalization
>> >> >> in my opinion.
>> >> >>
>> >> >> 2) w.r.t. forward-compatibility, one cannot make any suppositions
>> >> >> for
>> >> >> system's (kernel or userland) behavior in future versions/releases
>> >> >> for
>> >> >> practically anything (e.g. the key-generating hash in vnconfig may
>> >> >> not
>> >> >> be guaranteed to forever remain the same; the format of system calls
>> >> >> may change/evolve, disklabel format may/may-not change, sector-size
>> >> >> may become editable, etc.)... and I am certainly not looking this
>> >> >> far
>> >> >> into the future (i.e. namely and most-likely I am considering the
>> >> >> behavior wrt current kernel w/o such being upgraded continuously).
>> >> >> In
>> >> >> other words, I am perfectly happy to accept the failed 'mount/fsck'
>> >> >> attempts when/if differently-behaving kernel is being deployed.
>> >> >
>> >> > The source code defines the behaviour.
>> >> >
>> >> > Your words don't.
>> >> >
>> >>
>> >> Neither do yours :-) Although, some would also say that source code is
>> >> not always *defining*, but rather *implementing* the behavior (which
>> >> is standardized perhaps elsewhere)... but anyway -- potato, potato :-)
>> >
>> > Oh cut the crap.
>> >
>> > krw and I have a view how it should work, and we code it.
>> > Then the code is the behaviour.
>> >
>> > Perhaps we made mistakes.  Perhaps they'll be changed.
>> >
>> > But you are just spouting bullshit.
>> >
>>
>> :-) :-) :-) relax, take a pill -- no need to get emotional.
>>
>> besides I don't think we are seeing things that much differently. I
>> didn't say you were making mistakes, but if you make krap-inviting
>> statements like "the source code *defines* the behavior" then expect
>> the likewise, albeit not-that-serious, replies.
>>
>> Besides, the code may well be acting like implementation and
>> definition in one place, so no need to take such a heated bait to my
>> light replies. I'll stop now :-)
>>
>>
>> chill -- I don't mean to get a flame-war started, peace dude :-)
>
> I don't know who you are, but you do nothing.  What do you do?
>
> I don't see your name on any the source code.

Perhaps, but I am not going to enter any 'p*issing contests' of who's
got whose name where (besides, I am not implying to be an uber-coder,
but I do reserve the right to express my opinion wrt matter at hand).
I would like to retain the concentration on the matter discussed.

> The source code _does_ define the behaviour.  Exactly.  Perhaps the
> source code is wrong, but it *EXACTLY DEFINES THE BEHAVIOUR*.

All I was saying that it is not always the case. For example:

the code in various http client/server applications *implements* the
behavior (correctly or incorrectly as it may be), but the behavior is
*defined* elsewhere (e.g. a standard);

similar things could be said about the code in c compiler vs the c
standard et al.

Sometimes this may not be the case, of course, but to categorically
imply that 'code defines behavior' is not right in my opinion.

On the other hand -- perhaps we differ in our understanding of the
term "defines". You probably implying "defines" as in "results in a
given behavior", I am implying "defines" more in terms of
standardization/documentation (i.e. outline/definition of
rules/behavior).

Either way -- this only reinforces what I was saying wrt to not
expecting any future-compatible behavior of system and thus reducing
the scope of disklabel and 'c' partition arguments to the
"static/current" codebase behavior.

> So you shut up, loser.  Just go away.
>

Ok then. Be happy, take it easy.

leon.

[leon zadorin]

On 7/27/09, Marco Peereboom <slash@...> wrote:

>> :-) :-) :-) relax, take a pill -- no need to get emotional.
>>
>> besides I don't think we are seeing things that much differently. I
>> didn't say you were making mistakes, but if you make krap-inviting
>> statements like "the source code *defines* the behavior" then expect
>> the likewise, albeit not-that-serious, replies.
>>
>> Besides, the code may well be acting like implementation and
>> definition in one place, so no need to take such a heated bait to my
>> light replies. I'll stop now :-)
>>
>>
>> chill -- I don't mean to get a flame-war started, peace dude :-)
>
> Wow it is sunday night and you have used up all the manager-buzzword
> speak for an entire month.  What's next we have to go do some Agile
> programming while implementing Extreme Programming ideas for UML
> development that then becomes XML which we then can peruse for automated
> testing because humans should not test?

:-) :-) At least you exhibit some sense of humor :-)

I am not advocating the over-standardisation, I am merely noting that
in the absence of committed-to standards, it is futile to consider any
future-incompatible 'mood' of the kernel's behavior wrt issues
discussed (e.g. c partition). And I am also *not* advocating that one
should always strive towards any future-incompatible behavior -- only
that considering such possibilities wrt discussed 'kernel mood' would
be a moot (pun intended) point. That's all.

> If I am not VP material now I don't know what will...
>

... I don't know, tell me: "what will" ? :-)

[Marco Peereboom]

> Perhaps, but I am not going to enter any 'p*issing contests' of who's
> got whose name where (besides, I am not implying to be an uber-coder,
> but I do reserve the right to express my opinion wrt matter at hand).
> I would like to retain the concentration on the matter discussed.

Your opinion is wrong and uninteresting.  The only thing you have
expressed so far is your detachment from the real world by implying that
some sort of retarded document written by committee retards is somehow
important.

>
> > The source code _does_ define the behaviour.  Exactly.  Perhaps the
> > source code is wrong, but it *EXACTLY DEFINES THE BEHAVIOUR*.
>
> All I was saying that it is not always the case. For example:
>
> the code in various http client/server applications *implements* the
> behavior (correctly or incorrectly as it may be), but the behavior is
> *defined* elsewhere (e.g. a standard);

And in the real world all these standards are treated as guidelines.
Anyone who has written code from a "standard" know this.  This also
means that every person on this planet would interpret language the
same.  In the open source world people can't even agree what the word
"free" means.

>
> similar things could be said about the code in c compiler vs the c
> standard et al.

Show me 2 compilers and I'll show you 2 compilers that don't adhere to
the spec.

> Sometimes this may not be the case, of course, but to categorically
> imply that 'code defines behavior' is not right in my opinion.

It does.  Code is absolute, words on paper are not.

> On the other hand -- perhaps we differ in our understanding of the
> term "defines". You probably implying "defines" as in "results in a
> given behavior", I am implying "defines" more in terms of
> standardization/documentation (i.e. outline/definition of
> rules/behavior).

blah blah blah.

> Either way -- this only reinforces what I was saying wrt to not
> expecting any future-compatible behavior of system and thus reducing
> the scope of disklabel and 'c' partition arguments to the
> "static/current" codebase behavior.

Compatible with what?  The c partition is the whole disk, end of
discussion.  Don't know what a committee could ever add to that.

In fact I do know; they'd attach some arbitrary rules to show how smart
they are or to push some corporation's agenda.  The last thing they'd do
is push anything useful.

BTW, don't believe me?  Go read ACPI, SCSI & IPMI specs.  Then go write
the code.  Let me know how that went.

[leon zadorin]

On 7/28/09, Marco Peereboom <slash@...> wrote:

>> Perhaps, but I am not going to enter any 'p*issing contests' of who's
>> got whose name where (besides, I am not implying to be an uber-coder,
>> but I do reserve the right to express my opinion wrt matter at hand).
>> I would like to retain the concentration on the matter discussed.
>
> Your opinion is wrong and uninteresting.  The only thing you have
> expressed so far is your detachment from the real world by implying that
> some sort of retarded document written by committee retards is somehow
> important.
>

I didn't say this (although I also did not express any support for
having this general attitude towards standards as 'retarded documents
written by retards'). I think your (and others) emotions are getting
in a way of seeing the point I was making.

I am not imposing a qualitative resolution that everything which is
concerned with source code implementation must be standardized by a
committee.

You appear to have concluded that I am frowning at the fact that some
parts of the source code are somehow not committee-standardized --
this is not so.

I am simply noting (i.e. observing w/o blaming-others or anything of
such sort) that, in the absence of such (or similar) standards, any
consideration for what kernel's mood may bring in a future (e.g.
arbitrary changes of interpretation of what "entire physical disk"
equates to; ala "forward-compatibility") are not sufficient for the
arguments at hand.

In fact, I am not even suggesting that someone had made such
arguments, I was simply enumerating the reasons I thought were
relevant (and rather are easy to agree-on) when considering as to what
"kernel's mood" may be interpreted in the context of the originally
raised question (e.g. man pages implications for the disk to be
functional without any disklabel being written to it [man 5
disklabel], the reasons given for not using c partition in [man
vnconfig, caveats section] et al -- as per original email).

>>
>> > The source code _does_ define the behaviour.  Exactly.  Perhaps the
>> > source code is wrong, but it *EXACTLY DEFINES THE BEHAVIOUR*.
>>
>> All I was saying that it is not always the case. For example:
>>
>> the code in various http client/server applications *implements* the
>> behavior (correctly or incorrectly as it may be), but the behavior is
>> *defined* elsewhere (e.g. a standard);
>
> And in the real world all these standards are treated as guidelines.

Sure. But if such guidelines do exist -- should one not, at the very
least, attempt/strive towards meeting them (provided, of course, that
the standard/guidelines have been accepted by the implementing
community)?

We are basically starting to enter the whole discussion of viewing
what "implementation" vs "definition" mean and this was so not the
point of the original question.

Besides, I am sure you already realize, that just because one may not
be implementing the standard correctly -- it does not mean that one
should simply ignore the standard altogether.

> Anyone who has written code from a "standard" know this.  This also
> means that every person on this planet would interpret language the
> same.  In the open source world people can't even agree what the word
> "free" means.
>

Not every person on this planet may interpret the language the same --
but this does not mean that everyone should abandon well-defined
semantics attached to well-known words and start speaking their own
non-interoperable junk. This is even more so w.r.t.
technical/programming languages.

>>
>> similar things could be said about the code in c compiler vs the c
>> standard et al.
>
> Show me 2 compilers and I'll show you 2 compilers that don't adhere to
> the spec.

This is a bit of a moot point -- and I am sure you realize this
yourself. Not adhering to the specs does not equate to ignoring them
altogether.

>> Sometimes this may not be the case, of course, but to categorically
>> imply that 'code defines behavior' is not right in my opinion.
>
> It does.  Code is absolute, words on paper are not.

How you choose to represent the behavior's definition is irrelevant
(code or words, on paper or on screen).

I am, at this stage of conversation (if one can call it such), noting
the difference (in my opinion) between implementation and definition
-- and whilst there are cases when code represents both of such
concepts in one place; there are other places when there simply *must*
be multiple implementations (i.e. a source code of a given
app/library) of a given behavior/interface (standard) so that
different processes/boxes/entities/etc can inter-operate with each
other.

For instance: "Hello, how are you?" whether being written by me or by
you, on screen or on paper is still better than "AOAURRAOREAr naoe
as10 ao" ... right?

>> On the other hand -- perhaps we differ in our understanding of the
>> term "defines". You probably implying "defines" as in "results in a
>> given behavior", I am implying "defines" more in terms of
>> standardization/documentation (i.e. outline/definition of
>> rules/behavior).
>
> blah blah blah.

:-) :-) :-) Ignoring a point and making nonsensical noises are two
different things.

>> Either way -- this only reinforces what I was saying wrt to not
>> expecting any future-compatible behavior of system and thus reducing
>> the scope of disklabel and 'c' partition arguments to the
>> "static/current" codebase behavior.
>
> Compatible with what?  The c partition is the whole disk, end of
> discussion.  Don't know what a committee could ever add to that.

:-) When did I ever stated that some committee should standardize this?

I was commenting on man pages and that I was unclear on how I was
reading their content (one page appears to tell me that the disk does
not *need* to have disklabel to be installed at all and that the
kernel will provide one for it 'on-the-fly'; the other page appears to
say that c partition should not be used *because* fsck will need
disklabel for sector/block-finding purposes thus implying that c
partition needs a disklabel; yet another page implies a constant
semantic guarantee that 'c' partition does represent an entire and
physical disk; and then the email appeared to tell me that kernel's
"mood" can change c partition at will)... just look at the first
couple of emails in this thread for details.

All I was doing afterward is trying to restrict the context of what is
reasonable to expect w.r.t. to "kernel's mood" changing "arbitrarily"
and how such expectations should really only be conducted in the
context of current/static codebase (as there is no standard-based
commitment to future-compatibility -- *without* stating that I
expected such a future-compatible behavior to be made available).

> In fact I do know; they'd attach some arbitrary rules to show how smart
> they are or to push some corporation's agenda.  The last thing they'd do
> is push anything useful.
>
> BTW, don't believe me?  Go read ACPI, SCSI & IPMI specs.  Then go write
> the code.  Let me know how that went.
>

It's like I am trying to talk to you about apples and you are
vigorously arguing about oranges. I am *not* disagreeing with you
about oranges.

Leon.

[leon zadorin]

On 7/28/09, leon zadorin <leonleon77@...> wrote:

> How you choose to represent the behavior's definition is irrelevant
> (code or words, on paper or on screen).
>
> I am, at this stage of conversation (if one can call it such), noting
> the difference (in my opinion) between implementation and definition
> -- and whilst there are cases when code represents both of such
> concepts in one place; there are other places when there simply *must*
> be multiple implementations (i.e. a source code of a given
> app/library) of a given behavior/interface (standard) so that
> different processes/boxes/entities/etc can inter-operate with each
> other.
>
> For instance: "Hello, how are you?" whether being written by me or by
> you, on screen or on paper is still better than "AOAURRAOREAr naoe
> as10 ao" ... right?

I was, originally, a little hesitant of adding this extra note but
after some thought I might as well mention it... as it may provide
more clarity on the issue of this implementation vs definition
diversion from original question. This is only to show that, in fact,
I think we are saying common things, just in different terms.

I look at the actual ('raw') source code.

I then observe/derive a resulting behavior that such code would produce.

But I then also may want to optimize/improve the code (i.e. change it
with purposes of making the application perform better, faster, etc.)
-- but the question is: "by changing the code, some (insignificant)
aspects of the resulting behavior may change as well -- so which parts
of the resulting behavior are relied-upon/are-expected by other
applications and which fall in the 'irrelevant/insignificant or,
indeed, undefined' category"? One would need to know the boundaries of
code re-factoring when improving the *implementation* whilst still
retaining the interoperability-enabling interface/contract,
expected/*defined* behavior.

Whether such expectations (behavior definitions) are sometimes written
'inline' in the source code or in some standard publication is not the
main point really.

That's all I am saying. Feel free to ignore or make "blah blah blah" noises :-)

So now we can, perhaps, get back (if at all) to the man pages and what
they are implying wrt original question.

Leon.

[Otto Moerbeek]

On Tue, Jul 28, 2009 at 03:26:08PM +1000, leon zadorin wrote:

> That's all I am saying. Feel free to ignore or make "blah blah blah" noises :-)
>
> So now we can, perhaps, get back (if at all) to the man pages and what
> they are implying wrt original question.
>
> Leon.

I'm just back from vacation, so I'm late to jump in. The answer krw@
has given is right. We (and as a consequence the kernel) take the
liberty to change fields in disklabel, especially the entry for the
'c' partition.

Furthermore, there are partition specific entries used by fsck_ffs to
locate the alternate superblocks. These entries are NOT maintained for
the 'c' partition.

You might want to check the source of fsck_ffs. It contains code to
locate alternate superblocks, and that code will not work for the 'c'
partition.

As for the slighly off-topic part of the thread: if we write a
guideline into our manual page, it has a good reason to be there.
Consider the man page to be your much needed authorative source of
information.

        -Otto