Re: System unique identifier.....
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 be possible to have the kernel itself read in persistent > > > data (in some form such as getenv?) to be written to disk? That way, the > > > boot loader could pass it easily, and not have to worry about storage. > > > > This may sound like a heresy to you, but... Why don't use the Forth blocks > > for that? > > For what? Saving parametric data? That was always the plan, but the > last thing I think anyone wants to do is rewrite the ffs code in Forth. Ugh.. No, of course not. The former, i.e. saving parameters. I'm still sane, you know... :-) Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 be possible to have the kernel itself read in persistent > > > data (in some form such as getenv?) to be written to disk? That way, the > > > boot loader could pass it easily, and not have to worry about storage. > > > > This may sound like a heresy to you, but... Why don't use the Forth blocks > > for that? > > For what? Saving parametric data? That was always the plan, but the > last thing I think anyone wants to do is rewrite the ffs code in Forth. Ugh.. No, of course not. The former, i.e. saving parameters. I'm still sane, you know... :-) Andrzej Bialecki // <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> > 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 persistent > > data (in some form such as getenv?) to be written to disk? That way, the > > boot loader could pass it easily, and not have to worry about storage. > > This may sound like a heresy to you, but... Why don't use the Forth blocks > for that? For what? Saving parametric data? That was always the plan, but the last thing I think anyone wants to do is rewrite the ffs code in Forth. > They were invented for that purpose. We can create the files > beforehand (under normal OS operation), then from the bootloader we can > read and modify them - I suppose writing to a disk block is much easier > than through the filesystem layer... Yes, that's what we've always discussed as being the most likely course of action. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> > 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 persistent > > data (in some form such as getenv?) to be written to disk? That way, the > > boot loader could pass it easily, and not have to worry about storage. > > This may sound like a heresy to you, but... Why don't use the Forth blocks > for that? For what? Saving parametric data? That was always the plan, but the last thing I think anyone wants to do is rewrite the ffs code in Forth. > They were invented for that purpose. We can create the files > beforehand (under normal OS operation), then from the bootloader we can > read and modify them - I suppose writing to a disk block is much easier > than through the filesystem layer... Yes, that's what we've always discussed as being the most likely course of action. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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.conf[.local] qualify as persistent > > > data storage? > > > > There is little or no chance that the loader will gain the ability to > > write back to filesystems. Some of them don't support it (eg. > > iso9660), others may not (TFTP, NFS), and the code required for some of > > them (especially UFS) would be problematically large. > > 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 persistent > data (in some form such as getenv?) to be written to disk? That way, the > boot loader could pass it easily, and not have to worry about storage. This may sound like a heresy to you, but... Why don't use the Forth blocks for that? They were invented for that purpose. We can create the files beforehand (under normal OS operation), then from the bootloader we can read and modify them - I suppose writing to a disk block is much easier than through the filesystem layer... Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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.conf[.local] qualify as persistent > > > data storage? > > > > There is little or no chance that the loader will gain the ability to > > write back to filesystems. Some of them don't support it (eg. > > iso9660), others may not (TFTP, NFS), and the code required for some of > > them (especially UFS) would be problematically large. > > 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 persistent > data (in some form such as getenv?) to be written to disk? That way, the > boot loader could pass it easily, and not have to worry about storage. This may sound like a heresy to you, but... Why don't use the Forth blocks for that? They were invented for that purpose. We can create the files beforehand (under normal OS operation), then from the bootloader we can read and modify them - I suppose writing to a disk block is much easier than through the filesystem layer... Andrzej Bialecki // <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> > > > 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 ability to > > > write back to filesystems. Some of them don't support it (eg. > > > iso9660), others may not (TFTP, NFS), and the code required for some of > > > them (especially UFS) would be problematically large. > > > > But that's okay. If the persistent storage is the loader conf files, they > > can be updated from single or multi-user mode. > > There are cases where they need to be updated _by_the_loader_; see eg. > the "nextboot" manpage for functionality that we have currently lost. So much the better. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> > > 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 ability to > > write back to filesystems. Some of them don't support it (eg. > > iso9660), others may not (TFTP, NFS), and the code required for some of > > them (especially UFS) would be problematically large. > > But that's okay. If the persistent storage is the loader conf files, they > can be updated from single or multi-user mode. There are cases where they need to be updated _by_the_loader_; see eg. the "nextboot" manpage for functionality that we have currently lost. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> > > > 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 ability to > > > write back to filesystems. Some of them don't support it (eg. > > > iso9660), others may not (TFTP, NFS), and the code required for some of > > > them (especially UFS) would be problematically large. > > > > But that's okay. If the persistent storage is the loader conf files, they > > can be updated from single or multi-user mode. > > There are cases where they need to be updated _by_the_loader_; see eg. > the "nextboot" manpage for functionality that we have currently lost. So much the better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> > > 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 ability to > > write back to filesystems. Some of them don't support it (eg. > > iso9660), others may not (TFTP, NFS), and the code required for some of > > them (especially UFS) would be problematically large. > > But that's okay. If the persistent storage is the loader conf files, they > can be updated from single or multi-user mode. There are cases where they need to be updated _by_the_loader_; see eg. the "nextboot" manpage for functionality that we have currently lost. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 is little or no chance that the loader will gain the ability to > write back to filesystems. Some of them don't support it (eg. > iso9660), others may not (TFTP, NFS), and the code required for some of > them (especially UFS) would be problematically large. 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 persistent data (in some form such as getenv?) to be written to disk? That way, the boot loader could pass it easily, and not have to worry about storage. > > -- > \\ The mind's the standard \\ Mike Smith > \\ of the man. \\ msm...@freebsd.org > \\-- Joseph Merrick \\ msm...@cdrom.com > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 is little or no chance that the loader will gain the ability to > write back to filesystems. Some of them don't support it (eg. > iso9660), others may not (TFTP, NFS), and the code required for some of > them (especially UFS) would be problematically large. 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 persistent data (in some form such as getenv?) to be written to disk? That way, the boot loader could pass it easily, and not have to worry about storage. > > -- > \\ The mind's the standard \\ Mike Smith > \\ of the man. \\ [EMAIL PROTECTED] > \\-- Joseph Merrick \\ [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> > 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 ability to > write back to filesystems. Some of them don't support it (eg. > iso9660), others may not (TFTP, NFS), and the code required for some of > them (especially UFS) would be problematically large. But that's okay. If the persistent storage is the loader conf files, they can be updated from single or multi-user mode. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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 ability to write back to filesystems. Some of them don't support it (eg. iso9660), others may not (TFTP, NFS), and the code required for some of them (especially UFS) would be problematically large. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> > 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 ability to > write back to filesystems. Some of them don't support it (eg. > iso9660), others may not (TFTP, NFS), and the code required for some of > them (especially UFS) would be problematically large. But that's okay. If the persistent storage is the loader conf files, they can be updated from single or multi-user mode. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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 ability to write back to filesystems. Some of them don't support it (eg. iso9660), others may not (TFTP, NFS), and the code required for some of them (especially UFS) would be problematically large. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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 to read it. Probably not a problem because it really becomes more of a persistent boot property which is platform specific. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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 to read it. Probably not a problem because it really becomes more of a persistent boot property which is platform specific. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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...@freebsd.org "Misguided Angel hanging over me Heart like Gabriel, pure and white as ivory Soul like Lucifer, black and cold like a piece of lead..." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 PROTECTED] "Misguided Angel hanging over me Heart like Gabriel, pure and white as ivory Soul like Lucifer, black and cold like a piece of lead..." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 WWN assigned to by the manufacturer. > > > > Manufacturers have to register and 'get' a unique range they can assign > > to their products. How do you guarantee that your homegrown WWN is > > really unique? > > Witha a value in the top 4 bits that's not one of the currently defined > authoritative values. Not waterproof, at least to WW unique. What stops me from inventing exactly the same WWN as you do for your machine? Playing the devils (daemon's?) advocate, I admit.. > > > And to boot a Sun over fibre channel, you use the WWN. > > > > Well, we currently don't support that, but indeed that is what you would > > do. Tru64 Unix does something similar. > > > You can boot off of fibre channel now- but not using a WWN. Well, "we" is Compaq using a HSG80 FC raidbox on a Sun with a Jaycor adapter in the Sun. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 WWN assigned to by the manufacturer. > > > > Manufacturers have to register and 'get' a unique range they can assign > > to their products. How do you guarantee that your homegrown WWN is > > really unique? > > Witha a value in the top 4 bits that's not one of the currently defined > authoritative values. Not waterproof, at least to WW unique. What stops me from inventing exactly the same WWN as you do for your machine? Playing the devils (daemon's?) advocate, I admit.. > > > And to boot a Sun over fibre channel, you use the WWN. > > > > Well, we currently don't support that, but indeed that is what you would > > do. Tru64 Unix does something similar. > > > You can boot off of fibre channel now- but not using a WWN. Well, "we" is Compaq using a HSG80 FC raidbox on a Sun with a Jaycor adapter in the Sun. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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. > > Manufacturers have to register and 'get' a unique range they can assign > to their products. How do you guarantee that your homegrown WWN is > really unique? Witha a value in the top 4 bits that's not one of the currently defined authoritative values. > > > I think I'm confusing myself and people. I have a WWN. By definition it > > should be unique value. All I'm asking for is a kernel function to help me > > generate such a thing (despite what Eduardo says). > > > > > > On Fri, 25 Jun 1999, Wilko Bulte wrote: > > > > > 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 WWN to stay constant. > > > > > > Well, you do. Especially when you are using things like zoning (like > > > that Brocade switches can do) or when the host directly ties things to > > > the wwn it talks to. E.g. for connection to Sun we use Jaycor adapters > > > that allow things like "target=foo lun=bar www="<64bitnumber>" in the > > > Solaris /kernel/drv/sd.conf file > > > > And to boot a Sun over fibre channel, you use the WWN. > > Well, we currently don't support that, but indeed that is what you would > do. Tru64 Unix does something similar. You can boot off of fibre channel now- but not using a WWN. I want to see devfs fixed and using WWWs and/or device VPD. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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. > > Manufacturers have to register and 'get' a unique range they can assign > to their products. How do you guarantee that your homegrown WWN is > really unique? Witha a value in the top 4 bits that's not one of the currently defined authoritative values. > > > I think I'm confusing myself and people. I have a WWN. By definition it > > should be unique value. All I'm asking for is a kernel function to help me > > generate such a thing (despite what Eduardo says). > > > > > > On Fri, 25 Jun 1999, Wilko Bulte wrote: > > > > > 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 WWN to stay constant. > > > > > > Well, you do. Especially when you are using things like zoning (like > > > that Brocade switches can do) or when the host directly ties things to > > > the wwn it talks to. E.g. for connection to Sun we use Jaycor adapters > > > that allow things like "target=foo lun=bar www="<64bitnumber>" in the > > > Solaris /kernel/drv/sd.conf file > > > > And to boot a Sun over fibre channel, you use the WWN. > > Well, we currently don't support that, but indeed that is what you would > do. Tru64 Unix does something similar. You can boot off of fibre channel now- but not using a WWN. I want to see devfs fixed and using WWWs and/or device VPD. -matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 can assign to their products. How do you guarantee that your homegrown WWN is really unique? > I think I'm confusing myself and people. I have a WWN. By definition it > should be unique value. All I'm asking for is a kernel function to help me > generate such a thing (despite what Eduardo says). > > > On Fri, 25 Jun 1999, Wilko Bulte wrote: > > > 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 WWN to stay constant. > > > > Well, you do. Especially when you are using things like zoning (like > > that Brocade switches can do) or when the host directly ties things to > > the wwn it talks to. E.g. for connection to Sun we use Jaycor adapters > > that allow things like "target=foo lun=bar www="<64bitnumber>" in the > > Solaris /kernel/drv/sd.conf file > > And to boot a Sun over fibre channel, you use the WWN. Well, we currently don't support that, but indeed that is what you would do. Tru64 Unix does something similar. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 can assign to their products. How do you guarantee that your homegrown WWN is really unique? > I think I'm confusing myself and people. I have a WWN. By definition it > should be unique value. All I'm asking for is a kernel function to help me > generate such a thing (despite what Eduardo says). > > > On Fri, 25 Jun 1999, Wilko Bulte wrote: > > > 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 WWN to stay constant. > > > > Well, you do. Especially when you are using things like zoning (like > > that Brocade switches can do) or when the host directly ties things to > > the wwn it talks to. E.g. for connection to Sun we use Jaycor adapters > > that allow things like "target=foo lun=bar www="<64bitnumber>" in the > > Solaris /kernel/drv/sd.conf file > > And to boot a Sun over fibre channel, you use the WWN. Well, we currently don't support that, but indeed that is what you would do. Tru64 Unix does something similar. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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 platforms to support it), > you'd better come up with a less PC-centric place of storing this > information. The loader will, at some stage in the future, grow a persistent data store in which items like this can be saved. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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), > you'd better come up with a less PC-centric place of storing this > information. The loader will, at some stage in the future, grow a persistent data store in which items like this can be saved. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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 Alpha. There's NVRAM and so on for a lot of machines. I'm thinking that the cleanest place to put this which would be common across all *BSD's would be: a) A base release 128 bit UUID generator. b) A step in kernel configuration that snags such a value and puts it in a place that sysctl can get at it. c) A utility that binary patches the kernel so that a change via sysctl is persistent. All of this is quite grotesque. If it was FreeBSD specific, then stuff in /boot and sysctl would be fine- but I'd like to see this be *BSD, not just FreeBSD. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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 Alpha. There's NVRAM and so on for a lot of machines. I'm thinking that the cleanest place to put this which would be common across all *BSD's would be: a) A base release 128 bit UUID generator. b) A step in kernel configuration that snags such a value and puts it in a place that sysctl can get at it. c) A utility that binary patches the kernel so that a change via sysctl is persistent. All of this is quite grotesque. If it was FreeBSD specific, then stuff in /boot and sysctl would be fine- but I'd like to see this be *BSD, not just FreeBSD. -matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 Alpha. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 Alpha. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 platforms to support it), you'd better come up with a less PC-centric place of storing this information. -- Jason R. Thorpe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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), you'd better come up with a less PC-centric place of storing this information. -- Jason R. Thorpe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> > 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
Re: System unique identifier.....
> > 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 message
Re: System unique identifier.....
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 read prior to mounting root. But > > > where the linux folks aren't really hipped on is a good architecturally > > > clean place to store the seed. It'd be nice if we thought of this for > > > FreeBSD. > > > > Are there enough bytes available in the BIOS NVRAM? That would do > > nicely as a place to store it. > > Whose BIOS NVRAM? The host system BIOS NVRAM. I thought we were looking for a per-host ID here, right? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 read prior to mounting root. But > > > where the linux folks aren't really hipped on is a good architecturally > > > clean place to store the seed. It'd be nice if we thought of this for > > > FreeBSD. > > > > Are there enough bytes available in the BIOS NVRAM? That would do > > nicely as a place to store it. > > Whose BIOS NVRAM? The host system BIOS NVRAM. I thought we were looking for a per-host ID here, right? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> > > > 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 prior to mounting root. But > > where the linux folks aren't really hipped on is a good architecturally > > clean place to store the seed. It'd be nice if we thought of this for > > FreeBSD. > > Are there enough bytes available in the BIOS NVRAM? That would do > nicely as a place to store it. Whose BIOS NVRAM? This is not entirely architecturally even handed though. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> > > > 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 prior to mounting root. But > > where the linux folks aren't really hipped on is a good architecturally > > clean place to store the seed. It'd be nice if we thought of this for > > FreeBSD. > > Are there enough bytes available in the BIOS NVRAM? That would do > nicely as a place to store it. Whose BIOS NVRAM? This is not entirely architecturally even handed though. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 read prior to mounting root. But > where the linux folks aren't really hipped on is a good architecturally > clean place to store the seed. It'd be nice if we thought of this for > FreeBSD. Are there enough bytes available in the BIOS NVRAM? That would do nicely as a place to store it. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 read prior to mounting root. But > where the linux folks aren't really hipped on is a good architecturally > clean place to store the seed. It'd be nice if we thought of this for > FreeBSD. Are there enough bytes available in the BIOS NVRAM? That would do nicely as a place to store it. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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. All I'm asking for is a kernel function to help me generate such a thing (despite what Eduardo says). On Fri, 25 Jun 1999, Wilko Bulte wrote: > 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 WWN to stay constant. > > Well, you do. Especially when you are using things like zoning (like > that Brocade switches can do) or when the host directly ties things to > the wwn it talks to. E.g. for connection to Sun we use Jaycor adapters > that allow things like "target=foo lun=bar www="<64bitnumber>" in the > Solaris /kernel/drv/sd.conf file And to boot a Sun over fibre channel, you use the WWN. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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. All I'm asking for is a kernel function to help me generate such a thing (despite what Eduardo says). On Fri, 25 Jun 1999, Wilko Bulte wrote: > 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 WWN to stay constant. > > Well, you do. Especially when you are using things like zoning (like > that Brocade switches can do) or when the host directly ties things to > the wwn it talks to. E.g. for connection to Sun we use Jaycor adapters > that allow things like "target=foo lun=bar www="<64bitnumber>" in the > Solaris /kernel/drv/sd.conf file And to boot a Sun over fibre channel, you use the WWN. -matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 WWN to stay constant. Well, you do. Especially when you are using things like zoning (like that Brocade switches can do) or when the host directly ties things to the wwn it talks to. E.g. for connection to Sun we use Jaycor adapters that allow things like "target=foo lun=bar www="<64bitnumber>" in the Solaris /kernel/drv/sd.conf file -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 WWN to stay constant. Well, you do. Especially when you are using things like zoning (like that Brocade switches can do) or when the host directly ties things to the wwn it talks to. E.g. for connection to Sun we use Jaycor adapters that allow things like "target=foo lun=bar www="<64bitnumber>" in the Solaris /kernel/drv/sd.conf file -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> > > > 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 for each card, > > but then that requires all fabric clients to know (via some other > > arbitrary mechanism) that distinct WWNs are really the same 'box'. > > Existing FC RAID boxes have multiple controllers, each with a different > WWN. The port WWN is derived from the Node WWN. The Node WWN is in the > controller's PROM. In theory, when you swap one controller, the other > controller could remember the old node WWN and give it to the new > controller, but: > > If you swap both controllers, who's going to remember the old node WWNs? > > If you pull one controller from one box and stick it into another box, > then plug in a replacement controller into the first box, if the > replacement controller takes over the previous WWN, you could end up with > two different devices with the same WWN. I agree that this would be chaos, but you're using implementation to argue architecture. I'm thinking of a SANs of FreeBSD/NetBSD/Linux/Solaris boxes running simultaneous target/initiator mode on Fibre Channel. I can use WWN info wired into a specific card (whether it's the Port or Node WWN is solely at my discretion when I fire up the f/w and tell it what it it is), or I can choose something different entirely as the source of a WWN. As long as it's guaranteed unique in this domain, it's an acceptable design. > > Sure. That's reasonable enough, but not necessarily a problem that needs > > solving. The LUN isn't interesting in that what you want a known Node WWN > > for (routed to via multiple Port WWNs) so that when you construct the > > addressing to some physical box you, and intervening FC switches, can get > > the frame there. Beyond that, multilevel LUN numbers seem adequate for > > *within box* addressing, and then whatever volume management software > > needs to look at > > Thing is, the LUN is reachable through both controllers, each has a > different Node (and port) WWN. The FCP protocol layer should be > addressing these entities by LUN WWN. This means that it is responsible > for identifying the individual entities and establishing the mapping of > LUN WWN to associated Node WWNs. For boxes that support LUN WWN > > Thus multipathing needs to be done both at the FCP layer to handle the LUN > WWN <-> Node WWN mapping, as well as lower levels to deal with different > routes to different ports. > > Now you could allow the Node WWN to migrate between different physical > machines or controllers when handling failover, but if you did that you > would be violating the spirit, if not the letter of the Fibre Channel > specifications. This is a valid point- I'm going to mull about this some more then. > > Having said all that, I am a strong proponent of dumping all these silly > WWNs in the trash and embedding a volume identifier in the disklabel > itself. You really don't care all that much what device you're talking to > most of the time. What you really want is your data, so label the data > not the hardware. That's sct's (tweedie's) notion too. The answer to this is "Sometimes you *do* care about not only which specific one of N replicate data sets you have, and sometimes you even care about which path you took to get it". > > > At any rate, the WWN issue is just one use of this identifier. > > While the idea of a unique system identifier may have merit, I don't think > that generating node WWNs is an appropriate use for it. So, when are you gonna fix socal in Solaris to not use localetheraddr and a blind usage of hba instance (which has at least two level 2 bugs waiting to happen any day now) as a seed for cons'ed up WWNs? (*now* who's using implementation to argue architecture? :-;) -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> > > > 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 for each card, > > but then that requires all fabric clients to know (via some other > > arbitrary mechanism) that distinct WWNs are really the same 'box'. > > Existing FC RAID boxes have multiple controllers, each with a different > WWN. The port WWN is derived from the Node WWN. The Node WWN is in the > controller's PROM. In theory, when you swap one controller, the other > controller could remember the old node WWN and give it to the new > controller, but: > > If you swap both controllers, who's going to remember the old node WWNs? > > If you pull one controller from one box and stick it into another box, > then plug in a replacement controller into the first box, if the > replacement controller takes over the previous WWN, you could end up with > two different devices with the same WWN. I agree that this would be chaos, but you're using implementation to argue architecture. I'm thinking of a SANs of FreeBSD/NetBSD/Linux/Solaris boxes running simultaneous target/initiator mode on Fibre Channel. I can use WWN info wired into a specific card (whether it's the Port or Node WWN is solely at my discretion when I fire up the f/w and tell it what it it is), or I can choose something different entirely as the source of a WWN. As long as it's guaranteed unique in this domain, it's an acceptable design. > > Sure. That's reasonable enough, but not necessarily a problem that needs > > solving. The LUN isn't interesting in that what you want a known Node WWN > > for (routed to via multiple Port WWNs) so that when you construct the > > addressing to some physical box you, and intervening FC switches, can get > > the frame there. Beyond that, multilevel LUN numbers seem adequate for > > *within box* addressing, and then whatever volume management software > > needs to look at > > Thing is, the LUN is reachable through both controllers, each has a > different Node (and port) WWN. The FCP protocol layer should be > addressing these entities by LUN WWN. This means that it is responsible > for identifying the individual entities and establishing the mapping of > LUN WWN to associated Node WWNs. For boxes that support LUN WWN > > Thus multipathing needs to be done both at the FCP layer to handle the LUN > WWN <-> Node WWN mapping, as well as lower levels to deal with different > routes to different ports. > > Now you could allow the Node WWN to migrate between different physical > machines or controllers when handling failover, but if you did that you > would be violating the spirit, if not the letter of the Fibre Channel > specifications. This is a valid point- I'm going to mull about this some more then. > > Having said all that, I am a strong proponent of dumping all these silly > WWNs in the trash and embedding a volume identifier in the disklabel > itself. You really don't care all that much what device you're talking to > most of the time. What you really want is your data, so label the data > not the hardware. That's sct's (tweedie's) notion too. The answer to this is "Sometimes you *do* care about not only which specific one of N replicate data sets you have, and sometimes you even care about which path you took to get it". > > > At any rate, the WWN issue is just one use of this identifier. > > While the idea of a unique system identifier may have merit, I don't think > that generating node WWNs is an appropriate use for it. So, when are you gonna fix socal in Solaris to not use localetheraddr and a blind usage of hba instance (which has at least two level 2 bugs waiting to happen any day now) as a seed for cons'ed up WWNs? (*now* who's using implementation to argue architecture? :-;) -matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> > 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 Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 source you use, there's > > always the problem of "it broke; I had to replace it; now what?". > > Kind of like your grandfather's axe, which has had six handles and > > two blades over its lifetime, but it's still your grandfather's axe. > > I want it to persist until it's changed. Change doesn't mean a reboot. > > The practical side of this problem, which is a relatively trivial problem, > is to supply a consistent node WWN for fibre channel adapters that don't > have an assigned WWN in NVRAM. This only needs to be persistent across > reboots when I finish implementing the target mode code- a WWN identifying > a system as a 'device' needs to persist until told to change. 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. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> > 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 Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 source you use, there's > > always the problem of "it broke; I had to replace it; now what?". > > Kind of like your grandfather's axe, which has had six handles and > > two blades over its lifetime, but it's still your grandfather's axe. > > I want it to persist until it's changed. Change doesn't mean a reboot. > > The practical side of this problem, which is a relatively trivial problem, > is to supply a consistent node WWN for fibre channel adapters that don't > have an assigned WWN in NVRAM. This only needs to be persistent across > reboots when I finish implementing the target mode code- a WWN identifying > a system as a 'device' needs to persist until told to change. 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. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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 partner systems in a failover configuration). > > Matt, > > We've been hashing this issue out quite a bit. Since a Fibre Channel card I thought you might be! > 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. 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 for each card, but then that requires all fabric clients to know (via some other arbitrary mechanism) that distinct WWNs are really the same 'box'. What's the Leadville group's opinion on this? > The concept is that for SCSI disks and RAID boxen at least, the unique > identifier is the LUN WWN, which is the unique label for the data > contained on that LUN. The LUN WWN is 128 bits wide is generated from a > combination of the controller's node WWN and a timestamp, and is lost when > the LUN is destroyed. Sure. That's reasonable enough, but not necessarily a problem that needs solving. The LUN isn't interesting in that what you want a known Node WWN for (routed to via multiple Port WWNs) so that when you construct the addressing to some physical box you, and intervening FC switches, can get the frame there. Beyond that, multilevel LUN numbers seem adequate for *within box* addressing, and then whatever volume management software needs to look at > If you're not dealing with SCSI disks, well, I don't know if the standards > guys have considered that sort of situation yet. Yes indeed. At any rate, the WWN issue is just one use of this identifier. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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 partner systems in a failover configuration). > > Matt, > > We've been hashing this issue out quite a bit. Since a Fibre Channel card I thought you might be! > 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. 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 for each card, but then that requires all fabric clients to know (via some other arbitrary mechanism) that distinct WWNs are really the same 'box'. What's the Leadville group's opinion on this? > The concept is that for SCSI disks and RAID boxen at least, the unique > identifier is the LUN WWN, which is the unique label for the data > contained on that LUN. The LUN WWN is 128 bits wide is generated from a > combination of the controller's node WWN and a timestamp, and is lost when > the LUN is destroyed. Sure. That's reasonable enough, but not necessarily a problem that needs solving. The LUN isn't interesting in that what you want a known Node WWN for (routed to via multiple Port WWNs) so that when you construct the addressing to some physical box you, and intervening FC switches, can get the frame there. Beyond that, multilevel LUN numbers seem adequate for *within box* addressing, and then whatever volume management software needs to look at > If you're not dealing with SCSI disks, well, I don't know if the standards > guys have considered that sort of situation yet. Yes indeed. At any rate, the WWN issue is just one use of this identifier. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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 where it is stored. Yes. > > (2) Might be utterly useless (e.g. for software licensing, > especially when you have the source for the OS, and > can thus make it anything you want with a simple > kernel hack...) I'm not really concerned about this. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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. Yes. > > (2) Might be utterly useless (e.g. for software licensing, > especially when you have the source for the OS, and > can thus make it anything you want with a simple > kernel hack...) I'm not really concerned about this. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 just had a quick look at a Sun Ultra 3500. This has an SBus FC-AL card with two GBICs, each GBIC being connnected to a SENA. There's also another FC-AL built into the I/O module which attaches the internal disk backplane. Poking about with luxadm, I found that the SBus FC-AL has TWO WWNs (one for each channel), and each SENA also has a WWN. On one channel, the WWNs of the SBus card and the SENA are consecutive, but the two WWNs belonging to the SBus card aren't. As two of the GBICs were supplied separately, this sort of suggests that the WWN might live in the GBIC (rather than the SBus card or the SENA backplane). I couldn't get luxadm to show the WWNs for the FC-AL controller which connects the internal disk backplane, but presumably this has another two, so for this machine you might have 4 WWNs to choose from! Roger -- Roger Brooks (Systems Programmer), | Email: [EMAIL PROTECTED] Computing Services Dept,| Tel: +44 151 794 4441 The University of Liverpool,| Fax: +44 151 794 4442 PO Box 147, Liverpool L69 3BX, UK | -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 just had a quick look at a Sun Ultra 3500. This has an SBus FC-AL card with two GBICs, each GBIC being connnected to a SENA. There's also another FC-AL built into the I/O module which attaches the internal disk backplane. Poking about with luxadm, I found that the SBus FC-AL has TWO WWNs (one for each channel), and each SENA also has a WWN. On one channel, the WWNs of the SBus card and the SENA are consecutive, but the two WWNs belonging to the SBus card aren't. As two of the GBICs were supplied separately, this sort of suggests that the WWN might live in the GBIC (rather than the SBus card or the SENA backplane). I couldn't get luxadm to show the WWNs for the FC-AL controller which connects the internal disk backplane, but presumably this has another two, so for this machine you might have 4 WWNs to choose from! Roger -- Roger Brooks (Systems Programmer), | Email: r.s.bro...@liv.ac.uk Computing Services Dept,| Tel: +44 151 794 4441 The University of Liverpool,| Fax: +44 151 794 4442 PO Box 147, Liverpool L69 3BX, UK | -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 where it is stored. (2) Might be utterly useless (e.g. for software licensing, especially when you have the source for the OS, and can thus make it anything you want with a simple kernel hack...) -- Jason R. Thorpe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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. (2) Might be utterly useless (e.g. for software licensing, especially when you have the source for the OS, and can thus make it anything you want with a simple kernel hack...) -- Jason R. Thorpe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 settable system unique identifier, available > > prior to mountroot? This identifier has to be 64 bits or better and must > > be persistent across reboots. > > ...to be used for...? > 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 partner systems in a failover configuration). More generally a system unique identifier available early (pre mountroot) could be useful for a number of things. Why're you asking? -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 unique identifier, available > > prior to mountroot? This identifier has to be 64 bits or better and must > > be persistent across reboots. > > ...to be used for...? > 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 partner systems in a failover configuration). More generally a system unique identifier available early (pre mountroot) could be useful for a number of things. Why're you asking? -matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 identifier has to be 64 bits or better and must > be persistent across reboots. ...to be used for...? -- Jason R. Thorpe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
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 bits or better and must > be persistent across reboots. ...to be used for...? -- Jason R. Thorpe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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 mind. 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 source you use, there's > always the problem of "it broke; I had to replace it; now what?". > Kind of like your grandfather's axe, which has had six handles and > two blades over its lifetime, but it's still your grandfather's axe. > I want it to persist until it's changed. Change doesn't mean a reboot. The practical side of this problem, which is a relatively trivial problem, is to supply a consistent node WWN for fibre channel adapters that don't have an assigned WWN in NVRAM. This only needs to be persistent across reboots when I finish implementing the target mode code- a WWN identifying a system as a 'device' needs to persist until told to change. There's all sorts of good stuff for generating 128 UUIDs. That has multiple uses. I want it to be availble to the kernel, and that prior to reboot. It strikes me that some userland generation of UUID could be used to seed a particular kernel- which could be changed via sysctl as needed (w/o rebooting). I'm trying to think of the practical and least objectionable semantics of how to support that sooner rather than later. 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 prior to mounting root. But where the linux folks aren't really hipped on is a good architecturally clean place to store the seed. It'd be nice if we thought of this for FreeBSD. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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 mind. 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 source you use, there's > always the problem of "it broke; I had to replace it; now what?". > Kind of like your grandfather's axe, which has had six handles and > two blades over its lifetime, but it's still your grandfather's axe. > I want it to persist until it's changed. Change doesn't mean a reboot. The practical side of this problem, which is a relatively trivial problem, is to supply a consistent node WWN for fibre channel adapters that don't have an assigned WWN in NVRAM. This only needs to be persistent across reboots when I finish implementing the target mode code- a WWN identifying a system as a 'device' needs to persist until told to change. There's all sorts of good stuff for generating 128 UUIDs. That has multiple uses. I want it to be availble to the kernel, and that prior to reboot. It strikes me that some userland generation of UUID could be used to seed a particular kernel- which could be changed via sysctl as needed (w/o rebooting). I'm trying to think of the practical and least objectionable semantics of how to support that sooner rather than later. 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 prior to mounting root. But where the linux folks aren't really hipped on is a good architecturally clean place to store the seed. It'd be nice if we thought of this for FreeBSD. -matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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 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. This could start a long discussion :-}. 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 mind. The main issue, I think, is that of persistence. How persistent do you want it? I'd bet that no matter what source you use, there's always the problem of "it broke; I had to replace it; now what?". Kind of like your grandfather's axe, which has had six handles and two blades over its lifetime, but it's still your grandfather's axe. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
> 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 *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. This could start a long discussion :-}. 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 mind. The main issue, I think, is that of persistence. How persistent do you want it? I'd bet that no matter what source you use, there's always the problem of "it broke; I had to replace it; now what?". Kind of like your grandfather's axe, which has had six handles and two blades over its lifetime, but it's still your grandfather's axe. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
System unique identifier.....
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 to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
System unique identifier.....
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 to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
