James Carlson wrote:
Dick Davies writes:
On 02/06/06, James Carlson <[EMAIL PROTECTED]> wrote:
UNIX admin writes:
One of the rare things I like is how Linux solved this: regardless
of the networking HW, all interfaces are named "eth[0-N]", for
example eth0, eth1, ... , ethN.
Linux isn't the o
Dick Davies writes:
> On 02/06/06, James Carlson <[EMAIL PROTECTED]> wrote:
> > UNIX admin writes:
> > > One of the rare things I like is how Linux solved this: regardless
> > > of the networking HW, all interfaces are named "eth[0-N]", for
> > > example eth0, eth1, ... , ethN.
> >
> > Linux isn't
On 02/06/06, James Carlson <[EMAIL PROTECTED]> wrote:
UNIX admin writes:
> One of the rare things I like is how Linux solved this: regardless
> of the networking HW, all interfaces are named "eth[0-N]", for
> example eth0, eth1, ... , ethN.
Linux isn't the only one to do this. AIX, BSD, and oth
Darren J Moffat <[EMAIL PROTECTED]> wrote:
> James Carlson wrote:
> >> I also like the fact that for my laptop when running Linux, I don't have
> >> to remember how the network driver is called. But the above problem, how
> >> is it addressed on Linux ? On Solaris at least, that issue only occur
On Fri, Jun 02, 2006 at 03:23:25PM +0100, Darren J Moffat wrote:
> I think it is worse on Solaris because it looks like you can work it out
> and it appears to be predictable :-(
well, at least once you have a particular box's naming scheme worked out,
it is reasonably predictable.
"eri1" will AL
> One of the rare things I like in Linux, is how Linux
> solved this: regardless of the networking HW, all
> interfaces are named "eth[0-N]", for example eth0,
> eth1, ... , ethN.
>
> Perhaps this would be a solution to consider? There
> can still be bge0, and iprb0, iprb1 or ce0 in the
> system,
James Carlson wrote:
I also like the fact that for my laptop when running Linux, I don't have
to remember how the network driver is called. But the above problem, how
is it addressed on Linux ? On Solaris at least, that issue only occurs if
you have multiple cards of the same type... which isn'
UNIX admin writes:
> One of the rare things I like is how Linux solved this: regardless
> of the networking HW, all interfaces are named "eth[0-N]", for
> example eth0, eth1, ... , ethN.
Linux isn't the only one to do this. AIX, BSD, and other variants do
it as well.
> Perhaps this would be a so
On Fri, 2 Jun 2006, UNIX admin wrote:
Currently, the names of network interfaces are tied
to the
underlying hardware, for example, bge0.
This is so because of historical reasons, i.e. SunOS/BSD naming conventions,
which rely on networking HW having its own name.
One of the rare things I lik
> Currently, the names of network interfaces are tied
> to the
> underlying hardware, for example, bge0.
This is so because of historical reasons, i.e. SunOS/BSD naming conventions,
which rely on networking HW having its own name.
One of the rare things I like is how Linux solved this: regardl
[Apologize for the late clarification. We are aware of this thread
only very recently.]
There seems a lot of confusing around the Clearview project and
the /dev/net namespace it will introduce. As a team member of the
Clearview project, I'd like to make some clarification:
* A major component o
Is this perhaps Godwin's law for opensolaris-discuss?
I don't know.
(If a discussion on OpenSolaris lasts long enough, someone will mention
package tools)
(Perhaps because SVR4 tools leave something to be desired.)
___
opensolaris-discuss mailing
Hi James,
I agree, this topic has reached critical mass for a separate mailing
list and project. I think this is definitely an area in Solaris that
can be improved. I would be more than willing to support this either
thru its own community or thru the Systems Administrator community.
Octave
--
Octave Orgeron writes:
> prtdiag and cfgadm only help out so far. For example, prtdiag will tell you
> what's on a pci slot, but it does not tell you what instance that card
> matches up to. So you still have to look at /etc/path_to_inst or the links
> /dev to figure that out. Cfgadm is definite
> I do not think anyone mentioned /dev/root yet.
> If that is what IRIX6.5 was doing, there is no copy
> issue here.
You did write the following:
"- portable system device names.
e.g. replacing /dev/dsk/c0tWWNd0s0 with /dev/sys/root (RFE. 6311403)."
Which is conceptually exactly the same thing;
com
[EMAIL PROTECTED]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
- Original Message
From: Edward Pilatowicz <[EMAIL PROTECTED]>
To: Octave Orgeron <[EMAIL PROTECTED]>
Cc: Yonghong Lucy Lai <[EMAIL PROTECTED]>; opensolaris-discuss@opensolaris.org
Sent: Wednesday, May 31, 2006 1:46:12 PM
Subject: R
> To expand on Casper's post:
> http://finance.google.com/finance?fstype=bi&cid=655720
>
> I hope this makes it clear it's a *bit* more than "slightly more than a
> song."
I think I remember seeing that the shares were voided when they went into
bankruptcy. Now, they're pretty much in liquidati
> > Here is a real life example of the inconvenience
> > without a generic
> > root device name. In a sparc farm, a script is
> > written for jumpstart
> > 100 systems. It needs 100 copies of the jumpstart
> > scripts because
> > each system has it own WWN for the root device.
> > However, only
On Wed, May 31, 2006 at 12:31:17PM -0700, Octave Orgeron wrote:
> I agree that some consolidation and reorganization is required for the /dev
> tree. However, I do believe it's important to maintain compatibility. Many
> sysadmin's depend on knowing which device is on which pci bus, pci slot, or
To expand on Casper's post:
http://finance.google.com/finance?fstype=bi&cid=655720
I hope this makes it clear it's a *bit* more than "slightly more than a song."
- Original Message -
From: [EMAIL PROTECTED]
Date: Wednesday, May 31, 2006 10:33 am
Subject: Re: [o
>I think I've mentioned before that SGI can probably be bought for slightly
>more than a song. Ther
e's a couple of technologies that might be worth the cost to Sun.
Well, it's not "slightly more than a song"; there's the balance sheet
to consider and that isn't looking rosy. (You'll have to b
> So if you're going to be going that route, can we
> just have the rest of the IRIX 6.5 brought over into
> Solaris as well?
I think I've mentioned before that SGI can probably be bought for slightly more
than a song. There's a couple of technologies that might be worth the cost to
Sun.
-spp
>I still want `inst`, `swmgr` and `swpkg` from IRIX on Solaris...
Is this perhaps Godwin's law for opensolaris-discuss?
(If a discussion on OpenSolaris lasts long enough, someone will mention
package tools)
Casper
___
opensolaris-discuss mailing list
> Here is a real life example of the inconvenience
> without a generic
> root device name. In a sparc farm, a script is
> written for jumpstart
> 100 systems. It needs 100 copies of the jumpstart
> scripts because
> each system has it own WWN for the root device.
> However, only one copy
> is ne
p://unixconsole.blogspot.com
[EMAIL PROTECTED]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
- Original Message
From: Yonghong Lucy Lai <[EMAIL PROTECTED]>
To: opensolaris-discuss@opensolaris.org
Sent: Saturday, May 27, 2006 3:10:57 AM
Subject: [osol-discuss] Re: Project Proposal - "Simplified Solaris Device
> There are a lot
://unixconsole.blogspot.com
[EMAIL PROTECTED]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
- Original Message
From: Lucy Lai <[EMAIL PROTECTED]>
To: Peter Tribble <[EMAIL PROTECTED]>
Cc: opensolaris-discuss@opensolaris.org
Sent: Saturday, May 27, 2006 10:46:44 PM
Subject: Re: [osol-discuss]
> > > - flexible network device names.
> > > e.g. replacing /dev/bge0 with
> > /dev/net/192.168.1.0 (ref. ClearView).
> >
> > That's bollocks. What do you want to archive here?
> > Add another
> > maintenance hazard? IP addresses can change. Think
> > about mobile IP or
> > DHCP. Or just drive o
--- Peter Tribble <[EMAIL PROTECTED]> wrote:
> On Fri, 2006-05-26 at 20:55, Yonghong Lucy Lai
> wrote:
> > > I can't see any need to mess with physical
> names.)
> > I agree with you about the information offered in
> the WWN itself, and
> > I do not expect that information to go away from
> the
I. Szczesniak writes:
> > - Clearview needs the /dev/net namespace for the flexible interface
> > names and the zone-visible interfaces.
>
> The /dev/net name space just received it's first -1. The idea is a
> maintenance hazard and should not be implemented. Devices are hardware
> and /dev
> There are a lot more information on the Devname architecture
> that we have not discussed so far.
BACKGROUND
Solaris devices are represented in two name spaces: /dev and /devices. The
/devices namespace represents the physical path to a hardware device, a pseudo
device, or a bus nexus device.
> > - flexible network device names.
> > e.g. replacing /dev/bge0 with
> /dev/net/192.168.1.0 (ref. ClearView).
>
> That's bollocks. What do you want to archive here?
> Add another
> maintenance hazard? IP addresses can change. Think
> about mobile IP or
> DHCP. Or just drive our nice Thalys (a
> Quoting P.Tribble:
>
> > I see no advantage whatsoever to hiding important
> > information. What benefit can possibly accrue from
> > this?
>
> Cluster ?
We were talking about the possibility to revisit
the implementation of /dev/global.
> Grid Engine ?
Do you get any thoughts here?
lucy
On 5/26/06, James Carlson <[EMAIL PROTECTED]> wrote:
Yonghong Lucy Lai writes:
> >I'm not sure where Devname would fit in.
>
> There are a lot more information on the Devname architecture
> that we have not discussed so far.
>
> A biref here is that Devname is implementing a filesystem
> for the
Lucy,
On 5/26/06, Yonghong Lucy Lai <[EMAIL PROTECTED]> wrote:
..
There are a lot more information on the Devname architecture
that we have not discussed so far.
A biref here is that Devname is implementing a filesystem
for the /dev namespace. It supports mounting a subset of
the /dev namespace
On Fri, 2006-05-26 at 20:24, Yonghong Lucy Lai wrote:
> > > - persistent storage device names across the
> > enterprise.
> > > e.g. consistent name for a SANed tape drive (RFE.
> > 4096373).
> >
> > Does this mean additional links?
>
> A scenario for this problem is: In a shared SAN environment
On Fri, 2006-05-26 at 20:55, Yonghong Lucy Lai wrote:
> > I can't see any need to mess with physical names.)
> I agree with you about the information offered in the WWN itself, and
> I do not expect that information to go away from the system, either.
>
> Here is a real life example of the inconv
Yonghong Lucy Lai writes:
> >I'm not sure where Devname would fit in.
>
> There are a lot more information on the Devname architecture
> that we have not discussed so far.
>
> A biref here is that Devname is implementing a filesystem
> for the /dev namespace. It supports mounting a subset of
> t
On 5/26/06, Yonghong Lucy Lai <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-05-25 at 23:19, Yonghong Lai wrote:
> > The needs are accumulating for simplified Solaris
> device naming.
>
> Are they? Everything already has a simple, structured
> name.
It seems I did not convince you even with all the qu
> On Thu, 2006-05-25 at 23:19, Yonghong Lai wrote:
> > The needs are accumulating for simplified Solaris
> device naming.
>
> Are they? Everything already has a simple, structured
> name.
It seems I did not convince you even with all the quoted references.
Well, I am glad that you are happy with
> > - persistent storage device names across the
> enterprise.
> > e.g. consistent name for a SANed tape drive (RFE.
> 4096373).
>
> Does this mean additional links?
A scenario for this problem is: In a shared SAN environment,
the same tape device needs to be named the same on all the hosts
so
Quoting P.Tribble:
> I see no advantage whatsoever to hiding important
> information. What benefit can possibly accrue from
> this?
Cluster ?
Grid Engine ?
-- Tatjana
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
> On Thu, 2006-05-25 at 23:19, Yonghong Lai wrote:
> > The needs are accumulating for simplified Solaris
> device naming.
>
> Are they? Everything already has a simple, structured
> name.
>
> > Name a few here:
> > - persistent storage device names across the
> enterprise.
> > e.g. consistent n
42 matches
Mail list logo
