On Wed, 21 Jul 1999, Mike Smith wrote:
> > > That's not quite true. It wouldn't be too hard to modify existant files,
> > > but writing new ones/truncating would take a lot of work. It's still not
> > > a great idea to try to use a file on the FS for storage of persistent
> > > data. Wouldn't it b
On Wed, 21 Jul 1999, Mike Smith wrote:
> > > That's not quite true. It wouldn't be too hard to modify existant files,
> > > but writing new ones/truncating would take a lot of work. It's still not
> > > a great idea to try to use a file on the FS for storage of persistent
> > > data. Wouldn't it
> > That's not quite true. It wouldn't be too hard to modify existant files,
> > but writing new ones/truncating would take a lot of work. It's still not
> > a great idea to try to use a file on the FS for storage of persistent
> > data. Wouldn't it be possible to have the kernel itself read in per
> > That's not quite true. It wouldn't be too hard to modify existant files,
> > but writing new ones/truncating would take a lot of work. It's still not
> > a great idea to try to use a file on the FS for storage of persistent
> > data. Wouldn't it be possible to have the kernel itself read in pe
On Sun, 18 Jul 1999, Brian F. Feldman wrote:
> On Sun, 18 Jul 1999, Mike Smith wrote:
>
> > > Mike Smith wrote:
> > > >
> > > > The loader will, at some stage in the future, grow a persistent data
> > > > store in which items like this can be saved.
> > >
> > > Doesn't /boot/[defaults/]loader.c
On Sun, 18 Jul 1999, Brian F. Feldman wrote:
> On Sun, 18 Jul 1999, Mike Smith wrote:
>
> > > Mike Smith wrote:
> > > >
> > > > The loader will, at some stage in the future, grow a persistent data
> > > > store in which items like this can be saved.
> > >
> > > Doesn't /boot/[defaults/]loader.
> > > > Mike Smith wrote:
> > > > >
> > > > > The loader will, at some stage in the future, grow a persistent data
> > > > > store in which items like this can be saved.
> > > >
> > > > Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> > > > data storage?
> > >
> > > There is
> > > Mike Smith wrote:
> > > >
> > > > The loader will, at some stage in the future, grow a persistent data
> > > > store in which items like this can be saved.
> > >
> > > Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> > > data storage?
> >
> > There is little or no chanc
> > > > Mike Smith wrote:
> > > > >
> > > > > The loader will, at some stage in the future, grow a persistent data
> > > > > store in which items like this can be saved.
> > > >
> > > > Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> > > > data storage?
> > >
> > > There i
> > > Mike Smith wrote:
> > > >
> > > > The loader will, at some stage in the future, grow a persistent data
> > > > store in which items like this can be saved.
> > >
> > > Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> > > data storage?
> >
> > There is little or no chan
On Sun, 18 Jul 1999, Mike Smith wrote:
> > Mike Smith wrote:
> > >
> > > The loader will, at some stage in the future, grow a persistent data
> > > store in which items like this can be saved.
> >
> > Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> > data storage?
>
> There
On Sun, 18 Jul 1999, Mike Smith wrote:
> > Mike Smith wrote:
> > >
> > > The loader will, at some stage in the future, grow a persistent data
> > > store in which items like this can be saved.
> >
> > Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> > data storage?
>
> Ther
> > Mike Smith wrote:
> > >
> > > The loader will, at some stage in the future, grow a persistent data
> > > store in which items like this can be saved.
> >
> > Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> > data storage?
>
> There is little or no chance that the loader
> Mike Smith wrote:
> >
> > The loader will, at some stage in the future, grow a persistent data
> > store in which items like this can be saved.
>
> Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> data storage?
There is little or no chance that the loader will gain the abil
> > Mike Smith wrote:
> > >
> > > The loader will, at some stage in the future, grow a persistent data
> > > store in which items like this can be saved.
> >
> > Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> > data storage?
>
> There is little or no chance that the loader
> Mike Smith wrote:
> >
> > The loader will, at some stage in the future, grow a persistent data
> > store in which items like this can be saved.
>
> Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> data storage?
There is little or no chance that the loader will gain the abi
> Mike Smith wrote:
> >
> > The loader will, at some stage in the future, grow a persistent data
> > store in which items like this can be saved.
>
> Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> data storage?
Not if the items stored there are needed prior to being able
> Mike Smith wrote:
> >
> > The loader will, at some stage in the future, grow a persistent data
> > store in which items like this can be saved.
>
> Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> data storage?
Not if the items stored there are needed prior to being able
Mike Smith wrote:
>
> The loader will, at some stage in the future, grow a persistent data
> store in which items like this can be saved.
Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
data storage?
--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@free
Mike Smith wrote:
>
> The loader will, at some stage in the future, grow a persistent data
> store in which items like this can be saved.
Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
data storage?
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL
As Matthew Jacob wrote ...
>
>
> On Sat, 26 Jun 1999, Wilko Bulte wrote:
>
> > As Matthew Jacob wrote ...
> > >
> > > Yes, you want the WWN to stay constant. That doesn't mean it should
> > > necessarily be the same physical box. Nor does it mean it should be a
> > > system that comes with a W
As Matthew Jacob wrote ...
>
>
> On Sat, 26 Jun 1999, Wilko Bulte wrote:
>
> > As Matthew Jacob wrote ...
> > >
> > > Yes, you want the WWN to stay constant. That doesn't mean it should
> > > necessarily be the same physical box. Nor does it mean it should be a
> > > system that comes with a WW
On Sat, 26 Jun 1999, Wilko Bulte wrote:
> As Matthew Jacob wrote ...
> >
> > Yes, you want the WWN to stay constant. That doesn't mean it should
> > necessarily be the same physical box. Nor does it mean it should be a
> > system that comes with a WWN assigned to by the manufacturer.
>
> Manu
On Sat, 26 Jun 1999, Wilko Bulte wrote:
> As Matthew Jacob wrote ...
> >
> > Yes, you want the WWN to stay constant. That doesn't mean it should
> > necessarily be the same physical box. Nor does it mean it should be a
> > system that comes with a WWN assigned to by the manufacturer.
>
> Manuf
As Matthew Jacob wrote ...
>
> Yes, you want the WWN to stay constant. That doesn't mean it should
> necessarily be the same physical box. Nor does it mean it should be a
> system that comes with a WWN assigned to by the manufacturer.
Manufacturers have to register and 'get' a unique range they
As Matthew Jacob wrote ...
>
> Yes, you want the WWN to stay constant. That doesn't mean it should
> necessarily be the same physical box. Nor does it mean it should be a
> system that comes with a WWN assigned to by the manufacturer.
Manufacturers have to register and 'get' a unique range they c
> On Fri, 25 Jun 1999 15:55:03 -0600
> Wes Peters <[EMAIL PROTECTED]> wrote:
>
> > Are there enough bytes available in the BIOS NVRAM? That would do
> > nicely as a place to store it.
>
> If you want this to be widely adoped across the free OS community
> (hell, even if you want both of Fr
> On Fri, 25 Jun 1999 15:55:03 -0600
> Wes Peters wrote:
>
> > Are there enough bytes available in the BIOS NVRAM? That would do
> > nicely as a place to store it.
>
> If you want this to be widely adoped across the free OS community
> (hell, even if you want both of FreeBSD's platforms to
> Matthew Jacob wrote:
> >
> > > > Whose BIOS NVRAM?
> > >
> > > The host system BIOS NVRAM. I thought we were looking for a per-host
> > > ID here, right?
> >
> > Yes, but this kind of NVRAM isn't available on an Alpha, or a Sparc.
>
> On the SPARC you can put it in the OpenBoot environment.
> Matthew Jacob wrote:
> >
> > > > Whose BIOS NVRAM?
> > >
> > > The host system BIOS NVRAM. I thought we were looking for a per-host
> > > ID here, right?
> >
> > Yes, but this kind of NVRAM isn't available on an Alpha, or a Sparc.
>
> On the SPARC you can put it in the OpenBoot environment.
Matthew Jacob wrote:
>
> > > Whose BIOS NVRAM?
> >
> > The host system BIOS NVRAM. I thought we were looking for a per-host
> > ID here, right?
>
> Yes, but this kind of NVRAM isn't available on an Alpha, or a Sparc.
On the SPARC you can put it in the OpenBoot environment. I dunno
about the
Matthew Jacob wrote:
>
> > > Whose BIOS NVRAM?
> >
> > The host system BIOS NVRAM. I thought we were looking for a per-host
> > ID here, right?
>
> Yes, but this kind of NVRAM isn't available on an Alpha, or a Sparc.
On the SPARC you can put it in the OpenBoot environment. I dunno
about the A
On Fri, 25 Jun 1999 16:18:04 -0600
Wes Peters <[EMAIL PROTECTED]> wrote:
> > Whose BIOS NVRAM?
>
> The host system BIOS NVRAM. I thought we were looking for a per-host
> ID here, right?
I think Matt meant "which vendor's BIOS?"
-- Jason R. Thorpe <[EMAIL PROTECTED]>
To Unsubs
On Fri, 25 Jun 1999 15:55:03 -0600
Wes Peters <[EMAIL PROTECTED]> wrote:
> Are there enough bytes available in the BIOS NVRAM? That would do
> nicely as a place to store it.
If you want this to be widely adoped across the free OS community
(hell, even if you want both of FreeBSD's platform
On Fri, 25 Jun 1999 16:18:04 -0600
Wes Peters wrote:
> > Whose BIOS NVRAM?
>
> The host system BIOS NVRAM. I thought we were looking for a per-host
> ID here, right?
I think Matt meant "which vendor's BIOS?"
-- Jason R. Thorpe
To Unsubscribe: send mail to majord...@freebsd.o
On Fri, 25 Jun 1999 15:55:03 -0600
Wes Peters wrote:
> Are there enough bytes available in the BIOS NVRAM? That would do
> nicely as a place to store it.
If you want this to be widely adoped across the free OS community
(hell, even if you want both of FreeBSD's platforms to support it),
yo
> > Whose BIOS NVRAM?
>
> The host system BIOS NVRAM. I thought we were looking for a per-host
> ID here, right?
Yes, but this kind of NVRAM isn't available on an Alpha, or a Sparc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
> > Whose BIOS NVRAM?
>
> The host system BIOS NVRAM. I thought we were looking for a per-host
> ID here, right?
Yes, but this kind of NVRAM isn't available on an Alpha, or a Sparc.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the mess
Matthew Jacob wrote:
>
> > >
> > > I want it to persist until it's changed. Change doesn't mean a reboot.
> > >
> > > The Linux folks (mostly Ted) helped me clarify some thinking about this so
> > > that the basic original source of the seeded WWN doesn't have to come from
> > > first principles
Matthew Jacob wrote:
>
> > >
> > > I want it to persist until it's changed. Change doesn't mean a reboot.
> > >
> > > The Linux folks (mostly Ted) helped me clarify some thinking about this so
> > > that the basic original source of the seeded WWN doesn't have to come from
> > > first principles i
> >
> > I want it to persist until it's changed. Change doesn't mean a reboot.
> >
> > The Linux folks (mostly Ted) helped me clarify some thinking about this so
> > that the basic original source of the seeded WWN doesn't have to come from
> > first principles in hardware that can be read pri
> >
> > I want it to persist until it's changed. Change doesn't mean a reboot.
> >
> > The Linux folks (mostly Ted) helped me clarify some thinking about this so
> > that the basic original source of the seeded WWN doesn't have to come from
> > first principles in hardware that can be read prio
Matthew Jacob wrote:
>
> I want it to persist until it's changed. Change doesn't mean a reboot.
>
> The Linux folks (mostly Ted) helped me clarify some thinking about this so
> that the basic original source of the seeded WWN doesn't have to come from
> first principles in hardware that can be r
Matthew Jacob wrote:
>
> I want it to persist until it's changed. Change doesn't mean a reboot.
>
> The Linux folks (mostly Ted) helped me clarify some thinking about this so
> that the basic original source of the seeded WWN doesn't have to come from
> first principles in hardware that can be re
Yes, you want the WWN to stay constant. That doesn't mean it should
necessarily be the same physical box. Nor does it mean it should be a
system that comes with a WWN assigned to by the manufacturer.
I think I'm confusing myself and people. I have a WWN. By definition it
should be unique value.
Yes, you want the WWN to stay constant. That doesn't mean it should
necessarily be the same physical box. Nor does it mean it should be a
system that comes with a WWN assigned to by the manufacturer.
I think I'm confusing myself and people. I have a WWN. By definition it
should be unique value. A
As Matthew Jacob wrote ...
> >
> > FYI: The Compaq HSG80 Fibrechannel RAID controllers have their
> > WWN in NVRAM. One is supposed to get the WWN from a label on the *cabinet*
> > into the HSG controller. This allows for easy hardware swap in case of
> > hardware grief.
>
> Yes, if you want th
As Matthew Jacob wrote ...
> >
> > FYI: The Compaq HSG80 Fibrechannel RAID controllers have their
> > WWN in NVRAM. One is supposed to get the WWN from a label on the *cabinet*
> > into the HSG controller. This allows for easy hardware swap in case of
> > hardware grief.
>
> Yes, if you want the
> >
> > Really? Couldn't the Port WWN change and the Node WWN stay constant? I
> > mean, yes, for FC controllers that have WWN in the 0x2 range,
> > the Node WWN is 0x20... and the Port is 0x22... but it seems like this is
> > a soft relationship- you *could* have Port && Node unique
> >
> > Really? Couldn't the Port WWN change and the Node WWN stay constant? I
> > mean, yes, for FC controllers that have WWN in the 0x2 range,
> > the Node WWN is 0x20... and the Port is 0x22... but it seems like this is
> > a soft relationship- you *could* have Port && Node unique
>
> FYI: The Compaq HSG80 Fibrechannel RAID controllers have their
> WWN in NVRAM. One is supposed to get the WWN from a label on the *cabinet*
> into the HSG controller. This allows for easy hardware swap in case of
> hardware grief.
Yes, if you want the WWN to stay constant.
-matt
To Uns
As Matthew Jacob wrote ...
> Yes. The Solaris drivers use the 'localetheraddr' function, or's in 1<<60
> and then HBA instance # << 48 to make a NAA_IEEE port identifier.
>
> >
> > The main issue, I think, is that of persistence. How persistent do
> > you want it? I'd bet that no matter wha
>
> FYI: The Compaq HSG80 Fibrechannel RAID controllers have their
> WWN in NVRAM. One is supposed to get the WWN from a label on the *cabinet*
> into the HSG controller. This allows for easy hardware swap in case of
> hardware grief.
Yes, if you want the WWN to stay constant.
-matt
To Unsu
As Matthew Jacob wrote ...
> Yes. The Solaris drivers use the 'localetheraddr' function, or's in 1<<60
> and then HBA instance # << 48 to make a NAA_IEEE port identifier.
>
> >
> > The main issue, I think, is that of persistence. How persistent do
> > you want it? I'd bet that no matter what
> On Thu, 24 Jun 1999, Matthew Jacob wrote:
>
> > Specifically in this case a Node WWN for fibre channel fabrics that does
> > not depend upon an assigned WWN in any particular Fibre Channel card
> > (multipathing might make it desirable to have a synthetic Node WWN that
> > can also be passed t
> On Thu, 24 Jun 1999, Matthew Jacob wrote:
>
> > Specifically in this case a Node WWN for fibre channel fabrics that does
> > not depend upon an assigned WWN in any particular Fibre Channel card
> > (multipathing might make it desirable to have a synthetic Node WWN that
> > can also be passed to
> On Thu, 24 Jun 1999 23:41:34 -0700 (PDT)
> Matthew Jacob <[EMAIL PROTECTED]> wrote:
>
> > More generally a system unique identifier available early (pre mountroot)
> > could be useful for a number of things. Why're you asking?
>
> The intended usage
> On Thu, 24 Jun 1999 23:41:34 -0700 (PDT)
> Matthew Jacob wrote:
>
> > More generally a system unique identifier available early (pre mountroot)
> > could be useful for a number of things. Why're you asking?
>
> The intended usage:
>
> (1) Co
On Fri, 25 Jun 1999, Eduardo E. Horvath wrote:
>We've been hashing this issue out quite a bit. Since a Fibre Channel card
>is by definition a fibre channel controller, each card should have a
>unique WWN that is used for the node WWN. If you swap a controller, the
>node WWN should change.
I've
On Fri, 25 Jun 1999, Eduardo E. Horvath wrote:
>We've been hashing this issue out quite a bit. Since a Fibre Channel card
>is by definition a fibre channel controller, each card should have a
>unique WWN that is used for the node WWN. If you swap a controller, the
>node WWN should change.
I've
On Thu, 24 Jun 1999 23:41:34 -0700 (PDT)
Matthew Jacob <[EMAIL PROTECTED]> wrote:
> More generally a system unique identifier available early (pre mountroot)
> could be useful for a number of things. Why're you asking?
The intended usage:
(1) Could influence w
On Thu, 24 Jun 1999 23:41:34 -0700 (PDT)
Matthew Jacob wrote:
> More generally a system unique identifier available early (pre mountroot)
> could be useful for a number of things. Why're you asking?
The intended usage:
(1) Could influence where it is stored.
(
On Thu, 24 Jun 1999, Jason Thorpe wrote:
> On Thu, 24 Jun 1999 15:02:25 -0700 (PDT)
> Matthew Jacob <[EMAIL PROTECTED]> wrote:
>
> > I was talking about this on linux-kernel, but it also applies to *BSD...
> >
> > What're folks' motions of a s
On Thu, 24 Jun 1999, Jason Thorpe wrote:
> On Thu, 24 Jun 1999 15:02:25 -0700 (PDT)
> Matthew Jacob wrote:
>
> > I was talking about this on linux-kernel, but it also applies to *BSD...
> >
> > What're folks' motions of a settable system uniqu
On Thu, 24 Jun 1999 15:02:25 -0700 (PDT)
Matthew Jacob <[EMAIL PROTECTED]> wrote:
> I was talking about this on linux-kernel, but it also applies to *BSD...
>
> What're folks' motions of a settable system unique identifier, available
> prior to mountroot? This
On Thu, 24 Jun 1999 15:02:25 -0700 (PDT)
Matthew Jacob wrote:
> I was talking about this on linux-kernel, but it also applies to *BSD...
>
> What're folks' motions of a settable system unique identifier, available
> prior to mountroot? This identifier has to be 64 b
> Some systems just take the IEEE MAC address from the motherboard, or
> that of the first interface it finds. Others use some algorithmic
> variation on that value, but it generally boils down to the same
> thing. For newer Intel boxes, you could just use the CPU chip...
> well, never
> Some systems just take the IEEE MAC address from the motherboard, or
> that of the first interface it finds. Others use some algorithmic
> variation on that value, but it generally boils down to the same
> thing. For newer Intel boxes, you could just use the CPU chip...
> well, never m
> From: Matthew Jacob <[EMAIL PROTECTED]>
> Date: 1999-06-24 15:03:56 -0700
> To: [EMAIL PROTECTED]
> Subject: System unique identifier.
> Delivered-to: [EMAIL PROTECTED]
> X-Loop: FreeBSD.ORG
>
>
> I was talking about this on linux-kernel, but it also appli
> From: Matthew Jacob
> Date: 1999-06-24 15:03:56 -0700
> To: freebsd-hackers@FreeBSD.ORG
> Subject: System unique identifier.
> Delivered-to: freebsd-hackers@freebsd.org
> X-Loop: FreeBSD.ORG
>
>
> I was talking about this on linux-kernel, but it also applies to
I was talking about this on linux-kernel, but it also applies to *BSD...
What're folks' motions of a settable system unique identifier, available
prior to mountroot? This identifier has to be 64 bits or better and must
be persistent across reboots.
To Unsubscribe: send mail
I was talking about this on linux-kernel, but it also applies to *BSD...
What're folks' motions of a settable system unique identifier, available
prior to mountroot? This identifier has to be 64 bits or better and must
be persistent across reboots.
To Unsubscribe: send mail
72 matches
Mail list logo
