Re: LANANA: To Pending Device Number Registrants

[Stephen C. Tweedie]

Hi,

On Sat, May 19, 2001 at 04:20:11PM -0400, Michael Meissner wrote:
> On Fri, May 18, 2001 at 03:17:50PM +0100, Stephen C. Tweedie wrote:

> Presumably, a new UUID is created each time format a partition, which means it
> is a slight bit of hassle if you have to reload a partition from a dump, or
> copy a partition to another disk drive.  In the scheme of things, it is not a
> large hassle perhaps, but it is a hassle.

Right.  Tune2fs can reset the UUID on an existing filesystem, but if
you want something immune from the possible collisions of LABEL
namespaces, you can't really avoid ending up with different IDs on
filesystems after a restore.

Cheers,
 Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Albert D. Cahalan]

Guest section DW writes:
> On Thu, May 17, 2001 at 02:35:55AM -0400, Albert D. Cahalan wrote:

>> The PC partition table has such an ID. The LILO change log
>> mentions it. I think it's 6 random bytes, with some restriction
>> about being non-zero.
>
> You are confused. The partition table contains IDs, but these are
> the numbers like 83 for a Linux partition. No disk-identifying numbers.

Care to explain "duplicate MBR signature handling" in the GPT FAQ?
While describing the new-style partitions, Microsoft mentions that
Windows 2000 has a way to mark old-style ("MBR") partitions:

: 58. What happens if a duplicate Disk or Partition GUID is detected? 
: Windows Whistler will generate new GUIDs for any duplicate Disk GUID,
: MSR Partition GUID, or MSR basic data GUID upon detection. This is
: similar to the duplicate MBR signature handling in Windows 2000.
: Duplicate GUIDs on a dynamic container or database partition
: cause unpredictable results.

Well, the way to test this would be with Windows 2000, two disks,
and a Linux rescue disk that has "dd" on it. See what gets changed
when the "duplicate MBR signature handling in Windows 2000" runs.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Albert D. Cahalan]

Guest section DW writes:
 On Thu, May 17, 2001 at 02:35:55AM -0400, Albert D. Cahalan wrote:

 The PC partition table has such an ID. The LILO change log
 mentions it. I think it's 6 random bytes, with some restriction
 about being non-zero.

 You are confused. The partition table contains IDs, but these are
 the numbers like 83 for a Linux partition. No disk-identifying numbers.

Care to explain duplicate MBR signature handling in the GPT FAQ?
While describing the new-style partitions, Microsoft mentions that
Windows 2000 has a way to mark old-style (MBR) partitions:

: 58. What happens if a duplicate Disk or Partition GUID is detected? 
: Windows Whistler will generate new GUIDs for any duplicate Disk GUID,
: MSR Partition GUID, or MSR basic data GUID upon detection. This is
: similar to the duplicate MBR signature handling in Windows 2000.
: Duplicate GUIDs on a dynamic container or database partition
: cause unpredictable results.

Well, the way to test this would be with Windows 2000, two disks,
and a Linux rescue disk that has dd on it. See what gets changed
when the duplicate MBR signature handling in Windows 2000 runs.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Stephen C. Tweedie]

Hi,

On Sat, May 19, 2001 at 04:20:11PM -0400, Michael Meissner wrote:
 On Fri, May 18, 2001 at 03:17:50PM +0100, Stephen C. Tweedie wrote:

 Presumably, a new UUID is created each time format a partition, which means it
 is a slight bit of hassle if you have to reload a partition from a dump, or
 copy a partition to another disk drive.  In the scheme of things, it is not a
 large hassle perhaps, but it is a hassle.

Right.  Tune2fs can reset the UUID on an existing filesystem, but if
you want something immune from the possible collisions of LABEL
namespaces, you can't really avoid ending up with different IDs on
filesystems after a restore.

Cheers,
 Stephen
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Jonathan Lundell]

At 2:16 AM +1200 2001-05-21, Chris Wedgwood wrote:
>On Sat, May 19, 2001 at 10:36:14AM -0700, Jonathan Lundell wrote:
>
> I know from system documentation, or can figure out once and for
> all by experimentation, the correspondence between PCI
> bus/dev/fcn and physical locations. Jeff's extension gives me the
> mapping between eth# and PCI bus/dev/fcn, which is not otherwise
> available (outside the kernel).
>
>Won't work with hotplug PCI (consider plugging in something with a
>bridge).

It's true that hotplug devices make it more complicated, but I think 
the result can be achieved by describing the correspondence 
topologically rather than as a simple b/d/f-to-location table.
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Jonathan Lundell]

At 3:37 AM -0600 2001-05-20, Eric W. Biederman wrote:
>Jonathan Lundell <[EMAIL PROTECTED]> writes:
>
>>  At 10:42 AM +0200 2001-05-19, Kai Henningsen wrote:
>>  >  > Jeff Garzik's ethtool
>>  >  > extension at least tells me the PCI bus/dev/fcn, though, and from
>>  >>  that I can write a userland mapping function to the physical
>>  >>  location.
>>  >
>>  >I don't see how PCI bus/dev/fcn lets you do that.
>>
>>  I know from system documentation, or can figure out once and for all
>>  by experimentation, the correspondence between PCI bus/dev/fcn and
>>  physical locations. Jeff's extension gives me the mapping between
>>  eth# and PCI bus/dev/fcn, which is not otherwise available (outside
>>  the kernel).
>
>Just a second let me reenumerate your pci busses, and change all of the bus
>numbers.  Not that this is a bad thought.  It is just you need to know
>the tree of PCI busses/bridges up to the root on the machine in question.

Yes, you do. And it's true that renumbering is problematical; I 
hadn't thought of all the implications. Say, you have a system with 
hot-plug slots on two buses, and someone hot-plugs a card with a 
bridge (fairly common; most dual/quad Ethernet boards have a bridge). 
If the buses were numbered densely to begin with, they're going to 
have to be renumbered above the point that the new bridge was added.

Phooey. Well, it can still be done, but it's a bit more complicated 
than the bus/dev/fcn-to-location map I was imagining. You'd have to 
describe the topology of the built-in buses, and dynamically make the 
correspondences. As you say, "know the tree", by topology, not bus 
numbers.


-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Eric W. Biederman]

Jonathan Lundell <[EMAIL PROTECTED]> writes:

> At 10:42 AM +0200 2001-05-19, Kai Henningsen wrote:
> >  > Jeff Garzik's ethtool
> >  > extension at least tells me the PCI bus/dev/fcn, though, and from
> >>  that I can write a userland mapping function to the physical
> >>  location.
> >
> >I don't see how PCI bus/dev/fcn lets you do that.
> 
> I know from system documentation, or can figure out once and for all 
> by experimentation, the correspondence between PCI bus/dev/fcn and 
> physical locations. Jeff's extension gives me the mapping between 
> eth# and PCI bus/dev/fcn, which is not otherwise available (outside 
> the kernel).

Just a second let me reenumerate your pci busses, and change all of the bus
numbers.  Not that this is a bad thought.  It is just you need to know
the tree of PCI busses/bridges up to the root on the machine in question.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Eric W. Biederman]

Jonathan Lundell [EMAIL PROTECTED] writes:

 At 10:42 AM +0200 2001-05-19, Kai Henningsen wrote:
Jeff Garzik's ethtool
extension at least tells me the PCI bus/dev/fcn, though, and from
   that I can write a userland mapping function to the physical
   location.
 
 I don't see how PCI bus/dev/fcn lets you do that.
 
 I know from system documentation, or can figure out once and for all 
 by experimentation, the correspondence between PCI bus/dev/fcn and 
 physical locations. Jeff's extension gives me the mapping between 
 eth# and PCI bus/dev/fcn, which is not otherwise available (outside 
 the kernel).

Just a second let me reenumerate your pci busses, and change all of the bus
numbers.  Not that this is a bad thought.  It is just you need to know
the tree of PCI busses/bridges up to the root on the machine in question.

Eric
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Jonathan Lundell]

At 3:37 AM -0600 2001-05-20, Eric W. Biederman wrote:
Jonathan Lundell [EMAIL PROTECTED] writes:

  At 10:42 AM +0200 2001-05-19, Kai Henningsen wrote:
 Jeff Garzik's ethtool
 extension at least tells me the PCI bus/dev/fcn, though, and from
that I can write a userland mapping function to the physical
location.
  
  I don't see how PCI bus/dev/fcn lets you do that.

  I know from system documentation, or can figure out once and for all
  by experimentation, the correspondence between PCI bus/dev/fcn and
  physical locations. Jeff's extension gives me the mapping between
  eth# and PCI bus/dev/fcn, which is not otherwise available (outside
  the kernel).

Just a second let me reenumerate your pci busses, and change all of the bus
numbers.  Not that this is a bad thought.  It is just you need to know
the tree of PCI busses/bridges up to the root on the machine in question.

Yes, you do. And it's true that renumbering is problematical; I 
hadn't thought of all the implications. Say, you have a system with 
hot-plug slots on two buses, and someone hot-plugs a card with a 
bridge (fairly common; most dual/quad Ethernet boards have a bridge). 
If the buses were numbered densely to begin with, they're going to 
have to be renumbered above the point that the new bridge was added.

Phooey. Well, it can still be done, but it's a bit more complicated 
than the bus/dev/fcn-to-location map I was imagining. You'd have to 
describe the topology of the built-in buses, and dynamically make the 
correspondences. As you say, know the tree, by topology, not bus 
numbers.


-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Jonathan Lundell]

At 2:16 AM +1200 2001-05-21, Chris Wedgwood wrote:
On Sat, May 19, 2001 at 10:36:14AM -0700, Jonathan Lundell wrote:

 I know from system documentation, or can figure out once and for
 all by experimentation, the correspondence between PCI
 bus/dev/fcn and physical locations. Jeff's extension gives me the
 mapping between eth# and PCI bus/dev/fcn, which is not otherwise
 available (outside the kernel).

Won't work with hotplug PCI (consider plugging in something with a
bridge).

It's true that hotplug devices make it more complicated, but I think 
the result can be achieved by describing the correspondence 
topologically rather than as a simple b/d/f-to-location table.
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Michael Meissner]

On Fri, May 18, 2001 at 03:17:50PM +0100, Stephen C. Tweedie wrote:
> Hi,
> 
> On Wed, May 16, 2001 at 12:18:15PM -0400, Michael Meissner wrote:
> 
> > With the current LABEL= support, you won't be able to mount the disks with
> > duplicate labels, but you can still mount them via /dev/sd.
> 
> Or you can fall back to mounting by UUID, which is globally unique and
> still avoids referencing physical location.  You also don't need to
> manually set LABELs for UUID to work: all e2fsprogs over the past
> couple of years have set UUID on partitions, and e2fsck will create a
> new UUID if it sees an old filesystem that doesn't already have one.

Presumably, a new UUID is created each time format a partition, which means it
is a slight bit of hassle if you have to reload a partition from a dump, or
copy a partition to another disk drive.  In the scheme of things, it is not a
large hassle perhaps, but it is a hassle.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Number Registrants]

[Tim Jansen]

On Saturday 19 May 2001 21:43, Pavel Machek wrote:
> I think that plan9 uses something different -- they have ttyS0 and
> ttyS0ctl. This would leave us with problem "how do I get handle to
> ttyS0ctl when I only have handle to ttyS0"?

One possibility is to add multiforked (multi-stream) file support to Linux, 
then you could have a control stream. 


bye...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Number Registrants]

[Pavel Machek]

Hi!

> > Well, if we did something like modify(int fd, char *how), you could do
> > 
> > modify(0, "nonblock,9600") 
> 
> What you're really proposing is to make ioctl's be ASCII strings.

Yup.

> Which is not necessarily a bad idea, and I think plan9 did something
> similar (or rather, if I remember correctly, plan9 has control streams
> that were ASCII. Or am I confused?).

I think that plan9 uses something different -- they have ttyS0 and
ttyS0ctl. This would leave us with problem "how do I get handle to
ttyS0ctl when I only have handle to ttyS0"?

...

> However, you can't really use a string. It would really have to be two
> memory regions: incoming and outgoing, with an ASCII representation being
> the _preferred_ method for stuff that isn't obviously structured or
> performance-critical.

What are cases where it is usefull to pass data back from kernel?
...aha, serial controls include possibility to read stuff, right?

Pavel
-- 
The best software in life is free (not shareware)!  Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Number Registrants]

[Pavel Machek]

Hi!

> > > > >   fd = open("/dev/tty00/nonblock,9600,n8", O_RDWR);
> > > >
> > > > Hmm, there might be problem with this. How do you change speed without
> > > > reopening device? [Remember: your mice knows when you close device]
> 
> The naming scheme is not a replacement for these kinds of ioctl's - it's
> just a way to make them less critical, and get people thinking in other
> directions so that we don't get _more_ ioctl's.
> 
> Remember, the serial lines we already have legacy support for, that's not
> going away. The termios-based stuff isn't Linux-only, and we'll
> obviously maintain it for the forseeable future.

Well, if we did something like modify(int fd, char *how), you could do

modify(0, "nonblock,9600") 

which looks slightly better than special ioctl. You could even hack
libc to emulate ioctl with modify.

I thought about how to do networking without sockets, and it seems to
me like this kind of modify syscall is needed, because network sockets
connect to *two* different places (one local address and one
remote). Sockets are really nasty :-(.

> But if we can use naming to avoid ioctl's in the future, then THAT is
> good. I'm in particular thinking about frame-buffer and similar things,
> where we might be able to avoid making the situation worse.

Yup. OTOH making "new" system so powerfull that it could lead to
ioctls emulated in libc would be very nice, too.
Pavel
-- 
The best software in life is free (not shareware)!  Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Hans Reiser]

Chris Wedgwood wrote:
> 
> Or you can fall back to mounting by UUID, which is globally
> unique and still avoids referencing physical location.  You also
> don't need to manually set LABELs for UUID to work: all e2fsprogs
> over the past couple of years have set UUID on partitions, and
> e2fsck will create a new UUID if it sees an old filesystem that
> doesn't already have one.
> 
> Other filesystems such as reiserfs at present don't have such a
> thing. I brought this a while ago and in theory it's not too hard, we
> just need to get Hans to officially designate part of the SB or
> whatever for the UUID.
> 
>   --cw
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
work out a patch with monstr, and I am sure he will accept it.

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Jonathan Lundell]

At 10:42 AM +0200 2001-05-19, Kai Henningsen wrote:
>  > >Make your config script look at the hardware MAC addresses. Those don't
>>  >change.
>>
>>  They're not necessarily unique, though.
>
>So if you plug both into the same network segment, that segment is broken? 
>That looks like very stupid design to me.
>
>It's not as if getting enough unique MAC addresses was particularly 
>expensive. These days, even el-cheapo PC network cards get that right. 
>(And have for quite a number of years.)

Many do, some don't. Moreover, the MAC address is volatile in that it 
can be changed at will (via, eg, ifconfig).

I assume that the reason that Sun (for example) defaults to all MAC 
addresses on a system being the same is that it doesn't make sense, 
ordinarily, to plug two Ethernet interfaces into the same network 
segment. If, for some reason, you really want to do that, there's 
ifconfig ready to reassign the MAC address.

If I plug both into the same network segments by accident (because I 
can't tell which is which, say), then my configuration is nearly as 
broken with different MAC addresses as with identical ones; the fix 
is to replug correctly, not to change MAC addresses.
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Jonathan Lundell]

At 10:42 AM +0200 2001-05-19, Kai Henningsen wrote:
>  > Jeff Garzik's ethtool
>  > extension at least tells me the PCI bus/dev/fcn, though, and from
>>  that I can write a userland mapping function to the physical
>>  location.
>
>I don't see how PCI bus/dev/fcn lets you do that.

I know from system documentation, or can figure out once and for all 
by experimentation, the correspondence between PCI bus/dev/fcn and 
physical locations. Jeff's extension gives me the mapping between 
eth# and PCI bus/dev/fcn, which is not otherwise available (outside 
the kernel).
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Stephen C. Tweedie]

Hi,

On Sat, May 19, 2001 at 05:29:32PM +1200, Chris Wedgwood wrote:
> 
> Or you can fall back to mounting by UUID, which is globally
> unique and still avoids referencing physical location.  You also
> don't need to manually set LABELs for UUID to work: all e2fsprogs
> over the past couple of years have set UUID on partitions, and
> e2fsck will create a new UUID if it sees an old filesystem that
> doesn't already have one.
> 
> Other filesystems such as reiserfs at present don't have such a
> thing. I brought this a while ago and in theory it's not too hard, we
> just need to get Hans to officially designate part of the SB or
> whatever for the UUID.

There are other ways to deal with it: both md and (I think, in newer
releases) LVM can pick up their logical config from scanning physical
volumes for IDs, and so present a consistent logical device namespace
despite physical devices moving around. 

--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Pavel Machek]

Hi!

> > > > But no, I don't actually like sockets all that much myself. They are hard
> > > > to use from scripts, and many more people are familiar with open/close and
> > > > read/write.
> > > 
> > > Agreed.
> > > 
> > > It would be nice to use open/close/read/write for control and bulk and
> > > sockets for interrupt and isochronous.
> > 
> > What makes interrupt so different? Last time I checked int pipes were very
> > similar to bulk pipes... Do you care about "packet boundaries"? You can
> > somehow emulate with read, too...
> 
> We probably could. It would have interesting semantics however. We would
> have to have an ioctl or something else to specify period, and if it's
> one shot, etc.

ioctl for specifying period seems okay to me, and I believe UDP
sockets already have very similar semantics for read/write.

> We could probably shoehorn isochronous semantics onto read/write as
> well, but I don't want to begin to think how ugly that'll be.

What's the problem?

> A completely ioctl solution would work better in that case since it's
> cleaner. The only problem would be the fact it's called ioctl.

I do not think it is cleaner. Could AF_USB be used to get "clean"
solution?
Pavel
-- 
The best software in life is free (not shareware)!  Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

no ioctls for serial ports? [was Re: LANANA: To Pending Device Number Registrants]

[Pavel Machek]

Hi!

> > > They might also be exactly the same channel, except with certain magic
> > > bits set. The example peter gave was fine: tty devices could very usefully
> > > be opened with something like
> > > 
> > >   fd = open("/dev/tty00/nonblock,9600,n8", O_RDWR);
> > > 
> > > where we actually open up exactly the same channel as if we opened up
> > > /dev/cua00, we just set the speed etc at the same time. Which makes things
> > 
> > Hmm, there might be problem with this. How do you change speed without
> > reopening device? [Remember: your mice knows when you close device]
> 
> If you implement it as a filesystem you coould have a settings file in the
> tty filesystem. Something like this:
> 
> echo "115200" >  /dev/tty/settings

You can currently do 

stty 115200

or 

stty 19200

when your stdin is serial port. If it is filesystem, you'll have hard
time finding *which* of serial ports it is, followed by opening it.

What about this?

bash < /dev/ttyS0 &
rm -r /dev/ttyS0
how does bash change speed of serial line, then?
Pavel
-- 
The best software in life is free (not shareware)!  Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 17.05.01 in 
:

> At 11:23 PM +0200 2001-05-17, Kai Henningsen wrote:
> >[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 15.05.01 in
> >:
> >
> >>  What about:
> >>
> >>  1 (network domain). I have two network interfaces that I connect to
> >>  two different network segments, eth0 & eth1; they're ifconfig'd to
> >>  the appropriate IP and MAC addresses. I really do need to know
> >>  physically which (physical) hole to plug my eth0 cable into.
> >
> >Sorry, the software doesn't know that. Never has, for that matter.
>
> Well, no, it doesn't. That's a problem.

Maybe, but it's not a problem you can solve from the kernel.

> Jeff Garzik's ethtool
> extension at least tells me the PCI bus/dev/fcn, though, and from
> that I can write a userland mapping function to the physical
> location.

I don't see how PCI bus/dev/fcn lets you do that.

> My point, though, is that finding the socket is a real-life
> problem on systems with multiple interfaces. I don't expect the
> kernel to know the physical locations, but the user has to be able to
> get from kernel/ifconfig names (eth#) to sockets, one way or another.

Local documentation is just about the only way to do it.

And one way that'd work fairly well with at least PC network cards is  
putting a sticker with the MAC address on them where you can see it while  
looking for the right place to put your plug.

Not the only way, either.

> Support for a uniform means of doing the mapping, even if it needs
> userland help, would be good.

It doesn't need userland *or* kernel help.

> >  > (Extension: same situation, but it's a firewall and I've got 12 ports
> >>  to connect.) (Extension #2: if I add a NIC to the system and reboot,
> >>  I'd really prefer that the NICs already in use didn't get renumbered.)
> >
> >Make your config script look at the hardware MAC addresses. Those don't
> >change.
>
> They're not necessarily unique, though.

So if you plug both into the same network segment, that segment is broken?  
That looks like very stupid design to me.

It's not as if getting enough unique MAC addresses was particularly  
expensive. These days, even el-cheapo PC network cards get that right.  
(And have for quite a number of years.)

> >  > 2 (disk domain). I have multiple spindles on multiple SCSI adapters.
> >>  I want to allocate them to more than one RAID0/1/5 set, with the
> >>  usual considerations of putting mirrors on different adapters,
> >>  spreading my RAID5 drives optimally, ditto stripes. I need (eg) SCSI
> >>  paths to config all this, and I further need real physical locations
> >>  to identify failed drives that need to be hot-replaced. The mirror
> >>  members will move around as drives are replaced and hot spares come
> >>  into play.
> >
> >Use partition UUIDs, or SCSI serial numbers, or whatever. This works
> >today.
>
> This pushes the problem back in time: I need to write the UUID, for

But not the SCSI serial number.

> example, at some point. And, with hot-swappable drives, I'm still
> interested in the physical location. I really know know that there's
> a good answer to this problem, especially with FC, but I need to tell
> an operator, "replace this particular physical drive". It doesn't do
> any good to tell the operator the UUID.

Well, if it's a small system, any enumeration plus id-page query will let  
you identify *a* name for the device. There's no need for that name to be  
stable. (The only stable names you need are for mount and friends, and  
those can easily use UUIDs.)

In a big system, where presumably you use lots of similar drives, those  
better have some sort of serial number (which you can, of course, get at  
the same way as above). In that case, part of the preparation of a hot  
swap drive would be to put the serial number on a sticker on the drive (or  
put some other id there and note the correspondence in some database).

And, of course, your software can note which UUID goes with which serial  
number.

If your drives have *no* serial number, you can try a software one ... or  
follow the old advice: don't do that, then. Don't use unidentifiable  
drives in many-similar-drive production systems.

> >  > Seems like more that merely informational.
> >
> >The *location*? Nope. Some unique id for the device, if available at all:
> >sure.
>
> What good does it do to tell an operator to connect a cable to a MAC
> address? Or to remove a drive having a particular UUID? If it's "mere
> information", it's *necessary* mere information.

See above for how that works. As in, actually works in practice. As in, I  
really shouldn't have to explain this.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Johannes Erdfelt)  wrote on 17.05.01 in 
<[EMAIL PROTECTED]>:

> On Thu, May 17, 2001, Kai Henningsen <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] (Johannes Erdfelt)  wrote on 15.05.01 in
> > <[EMAIL PROTECTED]>:
> >
> > > I had always made the assumption that sockets were created because you
> > > couldn't easily map IPv4 semantics onto filesystems. It's unreasonable
> > > to have a file for every possible IP address/port you can communicate
> > > with.
> >
> > Not at all. What is unreasonable is douing a "ls" on the directory in
> > question.
> >
> > Big deal; make it mode d--x--x--x. Problem solved.
> >
> > And I'm pretty certain stuff like that *has* been done - wasn't there a
> > ftp file system where you could "ls /mountpoint/ftp.kernel.org/pub/linux"?
>
> I think this is the difference between reasonable and unreasonable.

What's unreasonable about it?

> I'm sure it could be done, but should it?

Well, the author of the Midnight Commander seems to think it should.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Johannes Erdfelt)  wrote on 17.05.01 in 
[EMAIL PROTECTED]:

 On Thu, May 17, 2001, Kai Henningsen [EMAIL PROTECTED] wrote:
  [EMAIL PROTECTED] (Johannes Erdfelt)  wrote on 15.05.01 in
  [EMAIL PROTECTED]:
 
   I had always made the assumption that sockets were created because you
   couldn't easily map IPv4 semantics onto filesystems. It's unreasonable
   to have a file for every possible IP address/port you can communicate
   with.
 
  Not at all. What is unreasonable is douing a ls on the directory in
  question.
 
  Big deal; make it mode d--x--x--x. Problem solved.
 
  And I'm pretty certain stuff like that *has* been done - wasn't there a
  ftp file system where you could ls /mountpoint/ftp.kernel.org/pub/linux?

 I think this is the difference between reasonable and unreasonable.

What's unreasonable about it?

 I'm sure it could be done, but should it?

Well, the author of the Midnight Commander seems to think it should.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 17.05.01 in 
p05100301b72a335d4b61@[10.128.7.49]:

 At 11:23 PM +0200 2001-05-17, Kai Henningsen wrote:
 [EMAIL PROTECTED] (Jonathan Lundell)  wrote on 15.05.01 in
 p05100316b7272cdfd50c@[207.213.214.37]:
 
   What about:
 
   1 (network domain). I have two network interfaces that I connect to
   two different network segments, eth0  eth1; they're ifconfig'd to
   the appropriate IP and MAC addresses. I really do need to know
   physically which (physical) hole to plug my eth0 cable into.
 
 Sorry, the software doesn't know that. Never has, for that matter.

 Well, no, it doesn't. That's a problem.

Maybe, but it's not a problem you can solve from the kernel.

 Jeff Garzik's ethtool
 extension at least tells me the PCI bus/dev/fcn, though, and from
 that I can write a userland mapping function to the physical
 location.

I don't see how PCI bus/dev/fcn lets you do that.

 My point, though, is that finding the socket is a real-life
 problem on systems with multiple interfaces. I don't expect the
 kernel to know the physical locations, but the user has to be able to
 get from kernel/ifconfig names (eth#) to sockets, one way or another.

Local documentation is just about the only way to do it.

And one way that'd work fairly well with at least PC network cards is  
putting a sticker with the MAC address on them where you can see it while  
looking for the right place to put your plug.

Not the only way, either.

 Support for a uniform means of doing the mapping, even if it needs
 userland help, would be good.

It doesn't need userland *or* kernel help.

(Extension: same situation, but it's a firewall and I've got 12 ports
   to connect.) (Extension #2: if I add a NIC to the system and reboot,
   I'd really prefer that the NICs already in use didn't get renumbered.)
 
 Make your config script look at the hardware MAC addresses. Those don't
 change.

 They're not necessarily unique, though.

So if you plug both into the same network segment, that segment is broken?  
That looks like very stupid design to me.

It's not as if getting enough unique MAC addresses was particularly  
expensive. These days, even el-cheapo PC network cards get that right.  
(And have for quite a number of years.)

2 (disk domain). I have multiple spindles on multiple SCSI adapters.
   I want to allocate them to more than one RAID0/1/5 set, with the
   usual considerations of putting mirrors on different adapters,
   spreading my RAID5 drives optimally, ditto stripes. I need (eg) SCSI
   paths to config all this, and I further need real physical locations
   to identify failed drives that need to be hot-replaced. The mirror
   members will move around as drives are replaced and hot spares come
   into play.
 
 Use partition UUIDs, or SCSI serial numbers, or whatever. This works
 today.

 This pushes the problem back in time: I need to write the UUID, for

But not the SCSI serial number.

 example, at some point. And, with hot-swappable drives, I'm still
 interested in the physical location. I really know know that there's
 a good answer to this problem, especially with FC, but I need to tell
 an operator, replace this particular physical drive. It doesn't do
 any good to tell the operator the UUID.

Well, if it's a small system, any enumeration plus id-page query will let  
you identify *a* name for the device. There's no need for that name to be  
stable. (The only stable names you need are for mount and friends, and  
those can easily use UUIDs.)

In a big system, where presumably you use lots of similar drives, those  
better have some sort of serial number (which you can, of course, get at  
the same way as above). In that case, part of the preparation of a hot  
swap drive would be to put the serial number on a sticker on the drive (or  
put some other id there and note the correspondence in some database).

And, of course, your software can note which UUID goes with which serial  
number.

If your drives have *no* serial number, you can try a software one ... or  
follow the old advice: don't do that, then. Don't use unidentifiable  
drives in many-similar-drive production systems.

Seems like more that merely informational.
 
 The *location*? Nope. Some unique id for the device, if available at all:
 sure.

 What good does it do to tell an operator to connect a cable to a MAC
 address? Or to remove a drive having a particular UUID? If it's mere
 information, it's *necessary* mere information.

See above for how that works. As in, actually works in practice. As in, I  
really shouldn't have to explain this.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

no ioctls for serial ports? [was Re: LANANA: To Pending Device Number Registrants]

[Pavel Machek]

Hi!

   They might also be exactly the same channel, except with certain magic
   bits set. The example peter gave was fine: tty devices could very usefully
   be opened with something like
   
 fd = open(/dev/tty00/nonblock,9600,n8, O_RDWR);
   
   where we actually open up exactly the same channel as if we opened up
   /dev/cua00, we just set the speed etc at the same time. Which makes things
  
  Hmm, there might be problem with this. How do you change speed without
  reopening device? [Remember: your mice knows when you close device]
 
 If you implement it as a filesystem you coould have a settings file in the
 tty filesystem. Something like this:
 
 echo 115200   /dev/tty/settings

You can currently do 

stty 115200

or 

stty 19200

when your stdin is serial port. If it is filesystem, you'll have hard
time finding *which* of serial ports it is, followed by opening it.

What about this?

bash  /dev/ttyS0 
rm -r /dev/ttyS0
how does bash change speed of serial line, then?
Pavel
-- 
The best software in life is free (not shareware)!  Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Pavel Machek]

Hi!

But no, I don't actually like sockets all that much myself. They are hard
to use from scripts, and many more people are familiar with open/close and
read/write.
   
   Agreed.
   
   It would be nice to use open/close/read/write for control and bulk and
   sockets for interrupt and isochronous.
  
  What makes interrupt so different? Last time I checked int pipes were very
  similar to bulk pipes... Do you care about packet boundaries? You can
  somehow emulate with read, too...
 
 We probably could. It would have interesting semantics however. We would
 have to have an ioctl or something else to specify period, and if it's
 one shot, etc.

ioctl for specifying period seems okay to me, and I believe UDP
sockets already have very similar semantics for read/write.

 We could probably shoehorn isochronous semantics onto read/write as
 well, but I don't want to begin to think how ugly that'll be.

What's the problem?

 A completely ioctl solution would work better in that case since it's
 cleaner. The only problem would be the fact it's called ioctl.

I do not think it is cleaner. Could AF_USB be used to get clean
solution?
Pavel
-- 
The best software in life is free (not shareware)!  Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Stephen C. Tweedie]

Hi,

On Sat, May 19, 2001 at 05:29:32PM +1200, Chris Wedgwood wrote:
 
 Or you can fall back to mounting by UUID, which is globally
 unique and still avoids referencing physical location.  You also
 don't need to manually set LABELs for UUID to work: all e2fsprogs
 over the past couple of years have set UUID on partitions, and
 e2fsck will create a new UUID if it sees an old filesystem that
 doesn't already have one.
 
 Other filesystems such as reiserfs at present don't have such a
 thing. I brought this a while ago and in theory it's not too hard, we
 just need to get Hans to officially designate part of the SB or
 whatever for the UUID.

There are other ways to deal with it: both md and (I think, in newer
releases) LVM can pick up their logical config from scanning physical
volumes for IDs, and so present a consistent logical device namespace
despite physical devices moving around. 

--Stephen
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Jonathan Lundell]

At 10:42 AM +0200 2001-05-19, Kai Henningsen wrote:
   Make your config script look at the hardware MAC addresses. Those don't
  change.

  They're not necessarily unique, though.

So if you plug both into the same network segment, that segment is broken? 
That looks like very stupid design to me.

It's not as if getting enough unique MAC addresses was particularly 
expensive. These days, even el-cheapo PC network cards get that right. 
(And have for quite a number of years.)

Many do, some don't. Moreover, the MAC address is volatile in that it 
can be changed at will (via, eg, ifconfig).

I assume that the reason that Sun (for example) defaults to all MAC 
addresses on a system being the same is that it doesn't make sense, 
ordinarily, to plug two Ethernet interfaces into the same network 
segment. If, for some reason, you really want to do that, there's 
ifconfig ready to reassign the MAC address.

If I plug both into the same network segments by accident (because I 
can't tell which is which, say), then my configuration is nearly as 
broken with different MAC addresses as with identical ones; the fix 
is to replug correctly, not to change MAC addresses.
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Jonathan Lundell]

At 10:42 AM +0200 2001-05-19, Kai Henningsen wrote:
   Jeff Garzik's ethtool
   extension at least tells me the PCI bus/dev/fcn, though, and from
  that I can write a userland mapping function to the physical
  location.

I don't see how PCI bus/dev/fcn lets you do that.

I know from system documentation, or can figure out once and for all 
by experimentation, the correspondence between PCI bus/dev/fcn and 
physical locations. Jeff's extension gives me the mapping between 
eth# and PCI bus/dev/fcn, which is not otherwise available (outside 
the kernel).
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Hans Reiser]

Chris Wedgwood wrote:
 
 Or you can fall back to mounting by UUID, which is globally
 unique and still avoids referencing physical location.  You also
 don't need to manually set LABELs for UUID to work: all e2fsprogs
 over the past couple of years have set UUID on partitions, and
 e2fsck will create a new UUID if it sees an old filesystem that
 doesn't already have one.
 
 Other filesystems such as reiserfs at present don't have such a
 thing. I brought this a while ago and in theory it's not too hard, we
 just need to get Hans to officially designate part of the SB or
 whatever for the UUID.
 
   --cw
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
work out a patch with monstr, and I am sure he will accept it.

Hans
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Number Registrants]

[Pavel Machek]

Hi!

   fd = open(/dev/tty00/nonblock,9600,n8, O_RDWR);
   
Hmm, there might be problem with this. How do you change speed without
reopening device? [Remember: your mice knows when you close device]
 
 The naming scheme is not a replacement for these kinds of ioctl's - it's
 just a way to make them less critical, and get people thinking in other
 directions so that we don't get _more_ ioctl's.
 
 Remember, the serial lines we already have legacy support for, that's not
 going away. The termios-based stuff isn't Linux-only, and we'll
 obviously maintain it for the forseeable future.

Well, if we did something like modify(int fd, char *how), you could do

modify(0, nonblock,9600) 

which looks slightly better than special ioctl. You could even hack
libc to emulate ioctl with modify.

I thought about how to do networking without sockets, and it seems to
me like this kind of modify syscall is needed, because network sockets
connect to *two* different places (one local address and one
remote). Sockets are really nasty :-(.

 But if we can use naming to avoid ioctl's in the future, then THAT is
 good. I'm in particular thinking about frame-buffer and similar things,
 where we might be able to avoid making the situation worse.

Yup. OTOH making new system so powerfull that it could lead to
ioctls emulated in libc would be very nice, too.
Pavel
-- 
The best software in life is free (not shareware)!  Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Number Registrants]

[Pavel Machek]

Hi!

  Well, if we did something like modify(int fd, char *how), you could do
  
  modify(0, nonblock,9600) 
 
 What you're really proposing is to make ioctl's be ASCII strings.

Yup.

 Which is not necessarily a bad idea, and I think plan9 did something
 similar (or rather, if I remember correctly, plan9 has control streams
 that were ASCII. Or am I confused?).

I think that plan9 uses something different -- they have ttyS0 and
ttyS0ctl. This would leave us with problem how do I get handle to
ttyS0ctl when I only have handle to ttyS0?

...

 However, you can't really use a string. It would really have to be two
 memory regions: incoming and outgoing, with an ASCII representation being
 the _preferred_ method for stuff that isn't obviously structured or
 performance-critical.

What are cases where it is usefull to pass data back from kernel?
...aha, serial controls include possibility to read stuff, right?

Pavel
-- 
The best software in life is free (not shareware)!  Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Number Registrants]

[Tim Jansen]

On Saturday 19 May 2001 21:43, Pavel Machek wrote:
 I think that plan9 uses something different -- they have ttyS0 and
 ttyS0ctl. This would leave us with problem how do I get handle to
 ttyS0ctl when I only have handle to ttyS0?

One possibility is to add multiforked (multi-stream) file support to Linux, 
then you could have a control stream. 


bye...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[James Simmons]

> > They might also be exactly the same channel, except with certain magic
> > bits set. The example peter gave was fine: tty devices could very usefully
> > be opened with something like
> > 
> > fd = open("/dev/tty00/nonblock,9600,n8", O_RDWR);
> > 
> > where we actually open up exactly the same channel as if we opened up
> > /dev/cua00, we just set the speed etc at the same time. Which makes things
> 
> Hmm, there might be problem with this. How do you change speed without
> reopening device? [Remember: your mice knows when you close device]

If you implement it as a filesystem you coould have a settings file in the
tty filesystem. Something like this:

echo "115200" >  /dev/tty/settings


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Mark H. Wood]

On Wed, 16 May 2001 [EMAIL PROTECTED] wrote:
> > The same situation appears when using bonding.o. For several years,
> > Don Becker's (and derived) network drivers support changing MAC address
> > when the interface is down. So Al's /dev/eth//MAC has different
> values
> > depending on whether bonding is active or not. Should /dev/eth//MAC
> > always have the original value (to be able to uniquely identify this
> card)
> > or the in-use value (used by ARP, I believe) ? Or maybe have a
> > /dev/eth//MAC_in_use ?
>
> Token ring has the same problem as well, most token ring adapters support
> setting a LAA.

Ethernet cards have both a fixed "hardware" address and the mutable
"physical" address.  How about TR?  And how many cards give you no access
to the hardware address?

-- 
Mark H. Wood, Lead System Programmer   [EMAIL PROTECTED]
Make a good day.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Johannes Erdfelt]

On Thu, May 17, 2001, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > But no, I don't actually like sockets all that much myself. They are hard
> > > to use from scripts, and many more people are familiar with open/close and
> > > read/write.
> > 
> > Agreed.
> > 
> > It would be nice to use open/close/read/write for control and bulk and
> > sockets for interrupt and isochronous.
> 
> What makes interrupt so different? Last time I checked int pipes were very
> similar to bulk pipes... Do you care about "packet boundaries"? You can
> somehow emulate with read, too...

We probably could. It would have interesting semantics however. We would
have to have an ioctl or something else to specify period, and if it's
one shot, etc.

We could probably shoehorn isochronous semantics onto read/write as
well, but I don't want to begin to think how ugly that'll be.

The reason I don't favor the read/write idea for interrupt and
isochronous are the fact that they are so different. We could shoehorn
the semantics onto it, but we'd just be moving the problem from one
place to somewhere else.

A completely ioctl solution would work better in that case since it's
cleaner. The only problem would be the fact it's called ioctl.

JE

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Pavel Machek]

Hi!
Hi!

> They might also be exactly the same channel, except with certain magic
> bits set. The example peter gave was fine: tty devices could very usefully
> be opened with something like
> 
>   fd = open("/dev/tty00/nonblock,9600,n8", O_RDWR);
> 
> where we actually open up exactly the same channel as if we opened up
> /dev/cua00, we just set the speed etc at the same time. Which makes things

Hmm, there might be problem with this. How do you change speed without
reopening device? [Remember: your mice knows when you close device]
Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Pavel Machek]

Hi!

> > But no, I don't actually like sockets all that much myself. They are hard
> > to use from scripts, and many more people are familiar with open/close and
> > read/write.
> 
> Agreed.
> 
> It would be nice to use open/close/read/write for control and bulk and
> sockets for interrupt and isochronous.

What makes interrupt so different? Last time I checked int pipes were very
similar to bulk pipes... Do you care about "packet boundaries"? You can
somehow emulate with read, too...
Pavel

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Stephen C. Tweedie]

Hi,

On Wed, May 16, 2001 at 12:18:15PM -0400, Michael Meissner wrote:

> With the current LABEL= support, you won't be able to mount the disks with
> duplicate labels, but you can still mount them via /dev/sd.

Or you can fall back to mounting by UUID, which is globally unique and
still avoids referencing physical location.  You also don't need to
manually set LABELs for UUID to work: all e2fsprogs over the past
couple of years have set UUID on partitions, and e2fsck will create a
new UUID if it sees an old filesystem that doesn't already have one.

Cheers,
 Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Heinz J. Mauelshagen]

On Thu, May 17, 2001 at 02:35:55AM -0400, Albert D. Cahalan wrote:
> Heinz J. Mauelshag writes:
> 
> > LVM does a similar thing storing UUIDs in its private metadata
> > area on every device used by it.
> >
> > Problem is: neither MD nor LVM define a standard in Linux
> > which *needs* to be used on every device!
> >
> > It is just up to the user to configure devices with them or not.
> >
> > BTW: in case we had a Linux standard it wouldn't solve the
> > "different OS" situation mentioned in this thread either.
> >
> >
> > Generally speaking:
> > 
> > It is not the problem to reserve some space to store a uuid or
> > something at such and such location on a device.
> >
> > The problem is the lack of a standard which eventually
> > could be implemented in all OSes at some point in time.
> 
> The PC partition table has such an ID. The LILO change log
> mentions it. I think it's 6 random bytes, with some restriction
> about being non-zero.

This is just a type identifier showing the parition type and just
valid on the PC.

Won't help it.

-- 

Regards,
Heinz-- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Brian Wheeler]

> 
> On Thursday 17 May 2001 22:00, Brian Wheeler wrote:
> > Consider an ID consisting of:
> > * vendor
> > * model
> 
> Vendor and model ids are available for PCI and USB devices, but I think you 
> can not assume that all busses have them and you dont gain anything if you 
> keep them separate (unless you want to interpret the fields of the device id).
> In other words I would merge them into a single field.
> 

I could see that.  In some cases (ISA devices in particular), they'd probably
be blank all of the time, and would be taken out of the equation.


> > * serial number
> > * content-cookie
> > * topology-cookie
> 
> You need another field that contains a identifier for the bus or the scheme 
> of the device id, because different busses use different formats and you 
> cannot compare them.

Since topology-cookie would be opaque, it doesn't matter what bus its sitting
onits either the same or its different.  As long as "pci bus 0, slot 1"
turns into the same cookie each time, and is always different than the 
"isa io=330" cookie then no problem.

> 
> You could also merge content-cookie and serial number because you will always 
> to interpret them together. 

Not necessarily, from other posts, serial number may or may not be unique.

All of the fields would probably be interpreted at the same time, but keeping
them separate would handle 'odd' cases that we've not thought of at this point.


> 
> >   I suppose these ID fields could also be used by a userspace tool to
> >   load/unload drivers as necessary.
> 
> There is a problem with that idea: you often cannot generate the device id 
> before the driver is available. Things like the content cookie and the serial 
> number must be created by the driver, at least in some cases. For example a 
> PCI ethernet card has a great serial number, its hardware address, but you 
> can only get it after the driver has been loaded.

Hmm.  True.  However, most of the other fields (Vendor/model, topology) would
be available before the driver is loaded.  Shouldn't that be enough to figure
which driver to use?  Of course, ISA devices cause problems here...come to
think of it, ISA devices cause problems no matter what we do :)

Brian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Alan Cox]

> > Consider an ID consisting of:
> > * vendor
> > * model
> 
> Vendor and model ids are available for PCI and USB devices, but I think you 
> can not assume that all busses have them and you dont gain anything if you 
> keep them separate (unless you want to interpret the fields of the device id).
> In other words I would merge them into a single field.

Well you actually want vendor,model, subvendor, submodel to cover PCI, and
you can add ISAPnP and PnPBIOS to your list of suitable devices


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Tim Jansen]

On Thursday 17 May 2001 22:00, Brian Wheeler wrote:
> Consider an ID consisting of:
>   * vendor
>   * model

Vendor and model ids are available for PCI and USB devices, but I think you 
can not assume that all busses have them and you dont gain anything if you 
keep them separate (unless you want to interpret the fields of the device id).
In other words I would merge them into a single field.

>   * serial number
>   * content-cookie
>   * topology-cookie

You need another field that contains a identifier for the bus or the scheme 
of the device id, because different busses use different formats and you 
cannot compare them.

You could also merge content-cookie and serial number because you will always 
to interpret them together. 

>   I suppose these ID fields could also be used by a userspace tool to
>   load/unload drivers as necessary.

There is a problem with that idea: you often cannot generate the device id 
before the driver is available. Things like the content cookie and the serial 
number must be created by the driver, at least in some cases. For example a 
PCI ethernet card has a great serial number, its hardware address, but you 
can only get it after the driver has been loaded.

bye...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Tim Jansen]

On Thursday 17 May 2001 22:00, Brian Wheeler wrote:
 Consider an ID consisting of:
   * vendor
   * model

Vendor and model ids are available for PCI and USB devices, but I think you 
can not assume that all busses have them and you dont gain anything if you 
keep them separate (unless you want to interpret the fields of the device id).
In other words I would merge them into a single field.

   * serial number
   * content-cookie
   * topology-cookie

You need another field that contains a identifier for the bus or the scheme 
of the device id, because different busses use different formats and you 
cannot compare them.

You could also merge content-cookie and serial number because you will always 
to interpret them together. 

   I suppose these ID fields could also be used by a userspace tool to
   load/unload drivers as necessary.

There is a problem with that idea: you often cannot generate the device id 
before the driver is available. Things like the content cookie and the serial 
number must be created by the driver, at least in some cases. For example a 
PCI ethernet card has a great serial number, its hardware address, but you 
can only get it after the driver has been loaded.

bye...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Alan Cox]

  Consider an ID consisting of:
  * vendor
  * model
 
 Vendor and model ids are available for PCI and USB devices, but I think you 
 can not assume that all busses have them and you dont gain anything if you 
 keep them separate (unless you want to interpret the fields of the device id).
 In other words I would merge them into a single field.

Well you actually want vendor,model, subvendor, submodel to cover PCI, and
you can add ISAPnP and PnPBIOS to your list of suitable devices


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Brian Wheeler]

 
 On Thursday 17 May 2001 22:00, Brian Wheeler wrote:
  Consider an ID consisting of:
  * vendor
  * model
 
 Vendor and model ids are available for PCI and USB devices, but I think you 
 can not assume that all busses have them and you dont gain anything if you 
 keep them separate (unless you want to interpret the fields of the device id).
 In other words I would merge them into a single field.
 

I could see that.  In some cases (ISA devices in particular), they'd probably
be blank all of the time, and would be taken out of the equation.


  * serial number
  * content-cookie
  * topology-cookie
 
 You need another field that contains a identifier for the bus or the scheme 
 of the device id, because different busses use different formats and you 
 cannot compare them.

Since topology-cookie would be opaque, it doesn't matter what bus its sitting
onits either the same or its different.  As long as pci bus 0, slot 1
turns into the same cookie each time, and is always different than the 
isa io=330 cookie then no problem.

 
 You could also merge content-cookie and serial number because you will always 
 to interpret them together. 

Not necessarily, from other posts, serial number may or may not be unique.

All of the fields would probably be interpreted at the same time, but keeping
them separate would handle 'odd' cases that we've not thought of at this point.


 
I suppose these ID fields could also be used by a userspace tool to
load/unload drivers as necessary.
 
 There is a problem with that idea: you often cannot generate the device id 
 before the driver is available. Things like the content cookie and the serial 
 number must be created by the driver, at least in some cases. For example a 
 PCI ethernet card has a great serial number, its hardware address, but you 
 can only get it after the driver has been loaded.

Hmm.  True.  However, most of the other fields (Vendor/model, topology) would
be available before the driver is loaded.  Shouldn't that be enough to figure
which driver to use?  Of course, ISA devices cause problems here...come to
think of it, ISA devices cause problems no matter what we do :)

Brian
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Heinz J. Mauelshagen]

On Thu, May 17, 2001 at 02:35:55AM -0400, Albert D. Cahalan wrote:
 Heinz J. Mauelshag writes:
 
  LVM does a similar thing storing UUIDs in its private metadata
  area on every device used by it.
 
  Problem is: neither MD nor LVM define a standard in Linux
  which *needs* to be used on every device!
 
  It is just up to the user to configure devices with them or not.
 
  BTW: in case we had a Linux standard it wouldn't solve the
  different OS situation mentioned in this thread either.
 
 
  Generally speaking:
  
  It is not the problem to reserve some space to store a uuid or
  something at such and such location on a device.
 
  The problem is the lack of a standard which eventually
  could be implemented in all OSes at some point in time.
 
 The PC partition table has such an ID. The LILO change log
 mentions it. I think it's 6 random bytes, with some restriction
 about being non-zero.

This is just a type identifier showing the parition type and just
valid on the PC.

Won't help it.

-- 

Regards,
Heinz-- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Stephen C. Tweedie]

Hi,

On Wed, May 16, 2001 at 12:18:15PM -0400, Michael Meissner wrote:

 With the current LABEL= support, you won't be able to mount the disks with
 duplicate labels, but you can still mount them via /dev/sdxxx.

Or you can fall back to mounting by UUID, which is globally unique and
still avoids referencing physical location.  You also don't need to
manually set LABELs for UUID to work: all e2fsprogs over the past
couple of years have set UUID on partitions, and e2fsck will create a
new UUID if it sees an old filesystem that doesn't already have one.

Cheers,
 Stephen
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Pavel Machek]

Hi!
Hi!

 They might also be exactly the same channel, except with certain magic
 bits set. The example peter gave was fine: tty devices could very usefully
 be opened with something like
 
   fd = open(/dev/tty00/nonblock,9600,n8, O_RDWR);
 
 where we actually open up exactly the same channel as if we opened up
 /dev/cua00, we just set the speed etc at the same time. Which makes things

Hmm, there might be problem with this. How do you change speed without
reopening device? [Remember: your mice knows when you close device]
Pavel
-- 
Philips Velo 1: 1x4x8, 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Pavel Machek]

Hi!

  But no, I don't actually like sockets all that much myself. They are hard
  to use from scripts, and many more people are familiar with open/close and
  read/write.
 
 Agreed.
 
 It would be nice to use open/close/read/write for control and bulk and
 sockets for interrupt and isochronous.

What makes interrupt so different? Last time I checked int pipes were very
similar to bulk pipes... Do you care about packet boundaries? You can
somehow emulate with read, too...
Pavel

-- 
Philips Velo 1: 1x4x8, 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Johannes Erdfelt]

On Thu, May 17, 2001, Pavel Machek [EMAIL PROTECTED] wrote:
   But no, I don't actually like sockets all that much myself. They are hard
   to use from scripts, and many more people are familiar with open/close and
   read/write.
  
  Agreed.
  
  It would be nice to use open/close/read/write for control and bulk and
  sockets for interrupt and isochronous.
 
 What makes interrupt so different? Last time I checked int pipes were very
 similar to bulk pipes... Do you care about packet boundaries? You can
 somehow emulate with read, too...

We probably could. It would have interesting semantics however. We would
have to have an ioctl or something else to specify period, and if it's
one shot, etc.

We could probably shoehorn isochronous semantics onto read/write as
well, but I don't want to begin to think how ugly that'll be.

The reason I don't favor the read/write idea for interrupt and
isochronous are the fact that they are so different. We could shoehorn
the semantics onto it, but we'd just be moving the problem from one
place to somewhere else.

A completely ioctl solution would work better in that case since it's
cleaner. The only problem would be the fact it's called ioctl.

JE

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Mark H. Wood]

On Wed, 16 May 2001 [EMAIL PROTECTED] wrote:
  The same situation appears when using bonding.o. For several years,
  Don Becker's (and derived) network drivers support changing MAC address
  when the interface is down. So Al's /dev/eth/n/MAC has different
 values
  depending on whether bonding is active or not. Should /dev/eth/n/MAC
  always have the original value (to be able to uniquely identify this
 card)
  or the in-use value (used by ARP, I believe) ? Or maybe have a
  /dev/eth/n/MAC_in_use ?

 Token ring has the same problem as well, most token ring adapters support
 setting a LAA.

Ethernet cards have both a fixed hardware address and the mutable
physical address.  How about TR?  And how many cards give you no access
to the hardware address?

-- 
Mark H. Wood, Lead System Programmer   [EMAIL PROTECTED]
Make a good day.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[James Simmons]

  They might also be exactly the same channel, except with certain magic
  bits set. The example peter gave was fine: tty devices could very usefully
  be opened with something like
  
  fd = open(/dev/tty00/nonblock,9600,n8, O_RDWR);
  
  where we actually open up exactly the same channel as if we opened up
  /dev/cua00, we just set the speed etc at the same time. Which makes things
 
 Hmm, there might be problem with this. How do you change speed without
 reopening device? [Remember: your mice knows when you close device]

If you implement it as a filesystem you coould have a settings file in the
tty filesystem. Something like this:

echo 115200   /dev/tty/settings


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Jonathan Lundell]

At 11:23 PM +0200 2001-05-17, Kai Henningsen wrote:
>[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 15.05.01 in 
>:
>
>>  What about:
>>
>>  1 (network domain). I have two network interfaces that I connect to
>>  two different network segments, eth0 & eth1; they're ifconfig'd to
>>  the appropriate IP and MAC addresses. I really do need to know
>>  physically which (physical) hole to plug my eth0 cable into.
>
>Sorry, the software doesn't know that. Never has, for that matter.

Well, no, it doesn't. That's a problem. Jeff Garzik's ethtool 
extension at least tells me the PCI bus/dev/fcn, though, and from 
that I can write a userland mapping function to the physical 
location. My point, though, is that finding the socket is a real-life 
problem on systems with multiple interfaces. I don't expect the 
kernel to know the physical locations, but the user has to be able to 
get from kernel/ifconfig names (eth#) to sockets, one way or another. 
Support for a uniform means of doing the mapping, even if it needs 
userland help, would be good.

>  > (Extension: same situation, but it's a firewall and I've got 12 ports
>>  to connect.) (Extension #2: if I add a NIC to the system and reboot,
>>  I'd really prefer that the NICs already in use didn't get renumbered.)
>
>Make your config script look at the hardware MAC addresses. Those don't
>change.

They're not necessarily unique, though.

>  > 2 (disk domain). I have multiple spindles on multiple SCSI adapters.
>>  I want to allocate them to more than one RAID0/1/5 set, with the
>>  usual considerations of putting mirrors on different adapters,
>>  spreading my RAID5 drives optimally, ditto stripes. I need (eg) SCSI
>>  paths to config all this, and I further need real physical locations
>>  to identify failed drives that need to be hot-replaced. The mirror
>>  members will move around as drives are replaced and hot spares come
>>  into play.
>
>Use partition UUIDs, or SCSI serial numbers, or whatever. This works
>today.

This pushes the problem back in time: I need to write the UUID, for 
example, at some point. And, with hot-swappable drives, I'm still 
interested in the physical location. I really know know that there's 
a good answer to this problem, especially with FC, but I need to tell 
an operator, "replace this particular physical drive". It doesn't do 
any good to tell the operator the UUID.

>  > Seems like more that merely informational.
>
>The *location*? Nope. Some unique id for the device, if available at all:
>sure.

What good does it do to tell an operator to connect a cable to a MAC 
address? Or to remove a drive having a particular UUID? If it's "mere 
information", it's *necessary* mere information.

>  > (A side observation: PCI or SCSI bus/device/lun/etc paths are not
>>  physical locations; you also need external hardware-specific
>>  knowledge to be able to talk about real physical locations in a way
>>  that does the system operator any good.)
>
>And those you typically do not have.

But (ideally) should.

-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Johannes Erdfelt]

On Thu, May 17, 2001, Kai Henningsen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Johannes Erdfelt)  wrote on 15.05.01 in 
><[EMAIL PROTECTED]>:
> 
> > I had always made the assumption that sockets were created because you
> > couldn't easily map IPv4 semantics onto filesystems. It's unreasonable
> > to have a file for every possible IP address/port you can communicate
> > with.
> 
> Not at all. What is unreasonable is douing a "ls" on the directory in  
> question.
> 
> Big deal; make it mode d--x--x--x. Problem solved.
> 
> And I'm pretty certain stuff like that *has* been done - wasn't there a  
> ftp file system where you could "ls /mountpoint/ftp.kernel.org/pub/linux"?

I think this is the difference between reasonable and unreasonable.

I'm sure it could be done, but should it?

JE

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (H. Peter Anvin)  wrote on 16.05.01 in 
<[EMAIL PROTECTED]>:

> At some point something talks to the device -- in this case, it's the
> SCSI layer.  Follow the interfaces in the kernel and it becomes obvious.

rc = sys_iskind(int filehandle, const char *driverkind)

rc = 0 or Esomething

Think of it as a generalization of isatty(). Maybe

#define isatty(f) sys_iskind(f, "tty")

:-;

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Richard Gooch)  wrote on 16.05.01 in 
<[EMAIL PROTECTED]>:

> H. Peter Anvin writes:
> > Richard Gooch wrote:
> > >
> > > H. Peter Anvin writes:
> > > > Richard Gooch wrote:
> > > > > Argh! What I wrote in text is what I meant to say. The code didn't
> > > > > match. No wonder people seemed to be missing the point. So the line
> > > > > of code I actually meant was:
> > > > > if (strcmp (buffer + len - 3, "/cd") != 0) {
> > > >
> > > > This is still a really bad idea.  You don't want to tie this kind of
> > > > things to the name.
> > >
> > > Why do you think it's a bad idea?
> >
> > Because you are now, once again, tying two things that are
> > completely and utterly unrelated: device classification and device
> > name.  It breaks every time someone comes out with a new device
> > which is "kind of like an old device, but not really," like
> > CD-writers (which was kind-of-like WORM, kind-of-like CD-ROM) and
> > DVD (kind-of-like CD)...
>
> But all devices which export a CD-ROM interface will do so. So the
> device node that is associated with the CD-ROM driver will export
> CD-ROM semantics, and the trailing name will be "/cd".

Uh, how do they have the filename end in more than one device type suffix  
at the same time?

That was the point, remember. You're trying to find out about a device on  
the end of your file handle, and that device *does* match more than one of  
these.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 15.05.01 in 
:

> What about:
>
> 1 (network domain). I have two network interfaces that I connect to
> two different network segments, eth0 & eth1; they're ifconfig'd to
> the appropriate IP and MAC addresses. I really do need to know
> physically which (physical) hole to plug my eth0 cable into.

Sorry, the software doesn't know that. Never has, for that matter.

> (Extension: same situation, but it's a firewall and I've got 12 ports
> to connect.) (Extension #2: if I add a NIC to the system and reboot,
> I'd really prefer that the NICs already in use didn't get renumbered.)

Make your config script look at the hardware MAC addresses. Those don't  
change.

> 2 (disk domain). I have multiple spindles on multiple SCSI adapters.
> I want to allocate them to more than one RAID0/1/5 set, with the
> usual considerations of putting mirrors on different adapters,
> spreading my RAID5 drives optimally, ditto stripes. I need (eg) SCSI
> paths to config all this, and I further need real physical locations
> to identify failed drives that need to be hot-replaced. The mirror
> members will move around as drives are replaced and hot spares come
> into play.

Use partition UUIDs, or SCSI serial numbers, or whatever. This works  
today.

> Seems like more that merely informational.

The *location*? Nope. Some unique id for the device, if available at all:  
sure.

> (A side observation: PCI or SCSI bus/device/lun/etc paths are not
> physical locations; you also need external hardware-specific
> knowledge to be able to talk about real physical locations in a way
> that does the system operator any good.)

And those you typically do not have.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 15.05.01 in 
<[EMAIL PROTECTED]>:

> They might also be exactly the same channel, except with certain magic
> bits set. The example peter gave was fine: tty devices could very usefully
> be opened with something like
>
>   fd = open("/dev/tty00/nonblock,9600,n8", O_RDWR);
>
> where we actually open up exactly the same channel as if we opened up
> /dev/cua00, we just set the speed etc at the same time. Which makes things
> a hell of a lot more readable, AND they are again easily done from
> scripts. The above is exactly the kind of thing that UNIX has not done
> well, and some others have done better (let's face it, even _DOS_ did it
> better, for chrissake! Those callout devices and those ioctl's are a pain
> in the ass, for no really good reason).

Umm ... where to begin.

1. No, DOS didn't do it better - DOS devices were mostly a bad copy of  
Xenix devices.

2. DOS definitely didn't do it better for serial ports. Serial ports are  
the single most broken devices that DOS supports by default, so much so  
that literally *no* serious program that needed the serial ports used the  
built-in driver. Only toy programs did that. Because those drivers weren't  
anything but toys themselves.

I know this the hard way. I used serial ports under DOS for something like  
ten years.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Johannes Erdfelt)  wrote on 15.05.01 in 
<[EMAIL PROTECTED]>:

> I had always made the assumption that sockets were created because you
> couldn't easily map IPv4 semantics onto filesystems. It's unreasonable
> to have a file for every possible IP address/port you can communicate
> with.

Not at all. What is unreasonable is douing a "ls" on the directory in  
question.

Big deal; make it mode d--x--x--x. Problem solved.

And I'm pretty certain stuff like that *has* been done - wasn't there a  
ftp file system where you could "ls /mountpoint/ftp.kernel.org/pub/linux"?

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Oliver Neukum]

On Thursday, 17. May 2001 18:58, Tim Jansen wrote:
> On Thursday 17 May 2001 08:43, Thomas Sailer wrote:
> > Cheap USB devices (and sometimes even expensive ones)
> > do not have serial numbers or other unique identifiers.
> > Therefore some sort of topology based addressing scheme
> > has to be used in that case.
>
> No, there is another addressing scheme that can be for devices without
> serial number: the vendor and product ids. Most people do not have two
> devices of the same kind, so you often do not need the topology at all.

We need to handle the case, even if it is rare. Thus the code must be there. 
If it is there we may as well use it.

Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Brian Wheeler]

[ I normally just lurk and read the archives, but...here's where I get into
  trouble! ]

It seems to me that there are several issues that have come up in this thread,
but here are my thoughts on some of them:

* Identifying hardware:
Since we don't want to use topology as the primary method of 
  identifying a device, perhaps it could be the secondary method.  If a device
  id consisted of several parts, userspace could make an educated guess about
  which devices correspond to which names, across reboots.  Consider an ID
  consisting of:
* vendor 
* model 
* serial number 
* content-cookie 
* topology-cookie 
  The two cookie values are opaque, but reproducable.  The content cookie might
  be an MD5 of the partition table of a disk, or its serial number, or 
  something to that effect.  The topology cookie would some topology 
  parameters (such as mem address, irq, io ports, slot #, etc) which could be 
  used to identify the device later.  These are only used for identification, 
  not for discovering topology.

  If all 5 fields match, then we know what it is.  If only topology-cookie is 
  different, then it just moved.  If content-cookie is different then it might
  be a different device  (There's a trickyness to partitioning, I suppose).

  I suppose these ID fields could also be used by a userspace tool to 
  load/unload drivers as necessary.

  The id could also determine the device is only inaccessable (not removed)
  when it disappears.  So, if disk5 disappeared on reboot, the next disk
  added would be given an ID at the end of the list, while disk5 would remain
  unused.  Only on a 'cleanup' would disk5 become reassignable.  This fixes
  issues like a device being unpowered on boot and a new one being powered up.


* User-space device naming
  I think the diskN naming is nice.  "randomly assigned" major ids won't be a
  problem, except on NFS mounted /dev directories.  If the kernel maintained
  a filesystem (like devfs or proc) which always managed the "currently 
  available" devices the only problem to solve would be dealing with software
  which opens the /dev node to get a driver loaded.

  
  It would be very cool if the dev filesystem could be exported to other linux
  boxes, so you could transparently have access to block devices (like nbd does
  now) and character devices (like the sound card)

  mount -t dev -o other_machine /dev/other_machine
  cat foo.au > /dev/other_machine/audio &
  


* IOCTL
  Since ioctl() is commonly regarded as a kluge, is there any reason why it
  couldn't be replaced by the /dev/fb0/frame0 thing that was described earlier?
  The libc implementation of ioctl could convert the binary data back into 
  text calls.  Gross, but possible...though it would probably be better to just
  depreciate the ioctl mechanism.   It could also package it for remote 
  usage (see my pipe_dream above).

  If device info/controls are tied to subdirectory entries, it would be nice
  to be able to get a device's capabilities via existance checking...
  I.E. '-e /dev/disk0/eject' could check of the device is ejectable.


Brian Wheeler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Jeff Randall]

Eric W. Biederman wrote:
> Daniel Phillips <[EMAIL PROTECTED]> writes:
> > On Tuesday 15 May 2001 23:20, Nicolas Pitre wrote:
> > > Personally, I'd really like to see /dev/ttyS0 be the first detected
> > > serial port on a system, /dev/ttyS1 the second, etc.
> > 
> > There are well-defined rules for the first four on PC's.  The ttySx 
> > better match the labels the OEM put on the box.
> 
> Actually it would be better to have the OEM put a label in the
> firmware, and then have a way to query the device for it's label.
> 
> The legacy rules are nice but serial ports are done with superio chips
> now.  And superio chips are almost all ISA PNP chips without device
> enumeration, and isolation. 

Not all serial ports are superio chips.  There's all kinds of serial
ports on all kinds of different busses being supported under Linux.  The
company I work for supports serial ports on ISA, PCI, SCSI, Ethernet, and
USB at the moment...


-- 
Jeff Randall - [EMAIL PROTECTED]  "A paranoid person is never alone,
   he knows he's always the center
   of attention..."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Mark H. Wood]

At the risk of offending hundreds, I'll mention that dynamic naming of
disks and tapes has worked very well for many years in VMS.  When you e.g.
mount a disk volume labelled FOO, the system creates a system logical name
DISK$FOO: for it automagically.  Users don't care that it's really
$4$DUA7: (which is *really* disk#5 on one HSCxx controller and disk#2 on
another one).  When you open DISK$FOO:[some.where]some.file , the kernel
knows what you meant.

Substitute ephemeral device special files for the system logical names and
you've got something like what's being discussed here.

Mind you, when that AI-thingy, I forget the name, suspects an impending
failure and wants to send me mail about it, *it* needs some way to tell me
which physical device needs replacing, so that I don't remove the wrong
one.  So physical locations have value, but only in special circumstances.
Ordinary end-use and daily system administration shouldn't employ them.

-- 
Mark H. Wood, Lead System Programmer   [EMAIL PROTECTED]
Make a good day.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Tim Jansen]

On Thursday 17 May 2001 19:18, you wrote:
> I wouldn't make that assumpation. I have two PS/2 keybaords attached to my
> system and they don't have serial ids nor do they have vendor or product
> ids.

Yes, PS/2 is a system where you must use the location. That's why a device id 
must contain the id, the serial number AND the location.

bye...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Geert Uytterhoeven]

On Thu, 17 May 2001, James Simmons wrote:
> > No, there is another addressing scheme that can be for devices without serial 
> > number: the vendor and product ids. Most people do not have two devices of 
> > the same kind, so you often do not need the topology at all.
> 
> I wouldn't make that assumpation. I have two PS/2 keybaords attached to my
> system and they don't have serial ids nor do they have vendor or product
> ids.

Yes. And it's the hardcore users who have multiple devices of the same kind.
Think e.g. RAID.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[James Simmons]

> No, there is another addressing scheme that can be for devices without serial 
> number: the vendor and product ids. Most people do not have two devices of 
> the same kind, so you often do not need the topology at all.

I wouldn't make that assumpation. I have two PS/2 keybaords attached to my
system and they don't have serial ids nor do they have vendor or product
ids.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Eric W. Biederman]

Daniel Phillips <[EMAIL PROTECTED]> writes:

> On Tuesday 15 May 2001 23:20, Nicolas Pitre wrote:
> > Personally, I'd really like to see /dev/ttyS0 be the first detected
> > serial port on a system, /dev/ttyS1 the second, etc.
> 
> There are well-defined rules for the first four on PC's.  The ttySx 
> better match the labels the OEM put on the box.

Actually it would be better to have the OEM put a label in the
firmware, and then have a way to query the device for it's label.

The legacy rules are nice but serial ports are done with superio chips
now.  And superio chips are almost all ISA PNP chips without device
enumeration, and isolation. 

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[David Brownell]

> For identifying this is probably the right approach. However identifying is 
> not enough, as the ioctl discussion has shown. Capabilities are needed. How 
> can the device registry provide that information ? 

My feedback on "device registry 0.1" was that I really liked the
approach of _modeling_ devices by attributes ... which reminded me
of the good things in "attribute based naming" a la X.500/LDAP
models.  I suspect 0.2 went too far, using XML to expose those
attributes to userspace ... :)

If each device had a directory node, those directory nodes could be
grouped as a "registry" ... the directory contents would list the various
bus-specific or type-specific capabilities/attributes.  Would those
directory nodes be the /dev/... or /devfs/... nodes?  I suspect not.


>If we register it together 
> with the device, we might spend a lot of resources needlessly and can't deal 
> with devices whose capabilities change dynamically.

So obviously such a registry should query the drivers/busses directly.


> In addition how do we export the information ? Proc ?

I think Tim has some ideas here, given a patch I scanned recently...

- Dave


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[James Simmons]

> Hmm.  It's interesting to me that there have been no replies discussing
> Tim's code.  Are any of you looking at it or do you simply think it is
> inconsequential and deserves to be ignored?
> Or, perhaps folks feel that it is off-topic?

Haven't had the chance to look at it. This weekend I will take a look.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Tim Jansen]

On Thursday 17 May 2001 08:43, Thomas Sailer wrote:
> Cheap USB devices (and sometimes even expensive ones)
> do not have serial numbers or other unique identifiers.
> Therefore some sort of topology based addressing scheme
> has to be used in that case.

No, there is another addressing scheme that can be for devices without serial 
number: the vendor and product ids. Most people do not have two devices of 
the same kind, so you often do not need the topology at all.

BTW this document describes the use of device ids on windows:
http://www.osr.com/ddk/idstrings_8tt3.htm

bye...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Tim Jansen]

On Thursday 17 May 2001 14:07, you wrote:
> For identifying this is probably the right approach. However identifying is
> not enough, as the ioctl discussion has shown. Capabilities are needed. How
> can the device registry provide that information ? 

The device registry provides you with device's capabilities and has different 
meachanisms for different needs:

- each device node has a type that describes the API (read/write format, 
ioctls) of the node. The type is set when you call devfs_register2 (a new 
version of devfs_register, set sets the node type and a connection to the 
physical device). So when you want to play pcm sound and your app supports 
OSS you search for the type "sound/oss/dsp"
- each physical device gets a type that is intended to be shown to the user 
and may be simplified. It can be used for things like selecting a appropriate 
icon for a device. It is not guaranteed to be correctly and some devices may 
not have a type.
- each bus subsystem and driver is free to add its own information. For 
example the PCI subsystem adds things like the interrupt, memory space and so 
on. User-space apps that dont know about it are required to ignore it. 


> If we register it together with the device, we might spend a lot of 
> resources needlessly and can't deal with devices whose capabilities 
> change dynamically.

No, the device and bus-subsystem information is generated on-demand, the type 
isnt guaranteed to be correct (and can be changed at any time) and the API of 
your device nodes hopefully doesnt change or otherwise you will really 
confuse the apps.


> In addition how do we export the information ? Proc ? Device nodes (bad for
> network devices) ?

The last version used a large XML file, but the next will expose the 
information in a (very) large number of proc files, each containing a single 
value. This required some changes in the proc API, but unfortunately I did 
not get a single comment on my patch 
(http://www.uwsg.indiana.edu/hypermail/linux/kernel/0105.1/1041.html)..

bye...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[James Simmons]

> > > USB disks are required (haha etc) to have serial numbers. Firewire similarly
> > > has unique disk identifiers.
> > 
> > How about for other device classes?
> 
> Keyboards and mice dont which is a real pig because it prevents you using
> dual head, two usb keyboards and 2 usb mice for a dual user box (assuming
> someone fixed the console code mess to cope with multiple console users as
> a concept)

Wrong!! I already have a multi-desktop system running at home. I have two
PS/2 keyboards, Sun keyboard, and a USB keyboard hooked up to my system. I
only have two monitors/video cards so I only have two VTs going at the
same time. I even managed to get two X servers running on each VT
independent of each other. This was not ease but it is possible. 
   I can tell you I didn't use any type of id system. How do I deal with
devices like multiple sound cards (yes I have that too) in a multidesktop
environment? With file permission on the device nodes. I created
different groups for different desktops. With a little tweaking with PAM
when I login to a specific workstation I'm automatically added to a
certain desktop group. I can't access any devices that belong to another 
desktop group. When I logout I'm removed from that group. Now xdm needs a
little hacking to make this work. 
   The beauty of this approach is the admin determines which devices
belong to which desktop. Now for hotpluggable devices when they plugged
back in a device they just unplugged and they don't end up on the same
device that new device will belong to no one. They can use some userland
utility then to grab the device. In this case it is first come first
serve. Surely when you plug in your device you are NOT going to steal a
device in use but one that is avaliable. Now what if two people unplug
their mice at the same time and plug them back in and they are mixed up.
Again I think a userland utility can solve this problem. Here you would
need to be root to fix the problem. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[David Brownell]

> > At this point of the discussion I would like to point to the Device Registry 
> > patch (http://www.tjansen.de/devreg) that already solves these problems and 
> > offers stable device ids for the identification of devices and finding their 
> > /dev nodes.
> > 
> > The devreg device id has four components: the bus identifier, the location of 
> > the device (for pci bus number and slot number, for usb the bus number and a 
> > list of port numbers), a model (product and device id) and, if available, a 
> > serial number. 
> 
> Hmm.  It's interesting to me that there have been no replies discussing
> Tim's code.  

I'd want to put it in the context of some of the USB work already done,
and also know how it generalizes to other busses ... 

For example, that usb-devname patch of mine, posted to linux-usb-devel
somewhere around 12/6/2000 (2.4.0-test12), which worked the issue
of teaching USB about "stable" identifiers (like pci slot_name, except
it didn't address functions within device configurations since PCI doesn't
have that notion of "configuration").

Or the patch providing a standard API for USB device drivers to report
what major/minor device numbers are associated with a given interface
(I think it was Alan Barnett who provided that).

Or the original (userspace) XML dump of XML tree structure, shown
at  http://jusb.sourceforge.net/?selected=tree ... it's not clear to me which
structural information there is also found in the "devreg" XML syntax
(from the kernel!), and which isn't.  (Class information omitted from
"devreg"?  Interface structure?)  Most of it's known to be needed.

For example, USB "bus numbers" are themselves unstable identifiers;
PCI slot_name fields work better, at least for host controllers (most!)
which use PCI.  If "devreg" uses "bus numbers", that needs to change.

- Dave


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Oliver Neukum]

> Since, as Alan mentioned, the lack of device serial numbers for USB mice
> and keyboards means that the only way to implement a relatively stable
> assignment of USB input devices to a quasi-multiuser system with
> multi-headed displays is by paying attention to USB topology, I would
> like us to explore any implementation that includes this support.  As
> Linus mentioned, this approach is unreliable, but it's all we have for
> these devices -- Topology can be disturbed by a variety of events
> (plugging a hub into a different host-controller port, etc).

For identifying this is probably the right approach. However identifying is 
not enough, as the ioctl discussion has shown. Capabilities are needed. How 
can the device registry provide that information ? If we register it together 
with the device, we might spend a lot of resources needlessly and can't deal 
with devices whose capabilities change dynamically.

In addition how do we export the information ? Proc ? Device nodes (bad for 
network devices) ?

Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Alan Cox]

> Linus, Is that wise? I could understand moratorium during 2.5, but during 2.4?!
> And worse, what about drivers that want to be merged into 2.2?

2.2 will be using the same forked registry as 2.4-ac. I dont anticipate much
being added to it that will need a major however

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Michael Meissner]

On Thu, May 17, 2001 at 04:46:33AM +0200, Willem Konynenberg wrote:
> I think here we might learn from the comments that people made
> about how AIX and OSF/1/Tru64 have been doing this.

However, I suspect that generally AIX and OSF/1 Tru64 systems come with system
managers.  Many Linux system do not (well presumably anybody who reads this
mailing list has enough of a clue).  Also, I bet the number of USB and
Firewire devices used on the above two systems is probably vanishingly small.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Guest section DW]

On Thu, May 17, 2001 at 02:35:55AM -0400, Albert D. Cahalan wrote:

> The PC partition table has such an ID. The LILO change log
> mentions it. I think it's 6 random bytes, with some restriction
> about being non-zero.

You are confused. The partition table contains IDs, but these are
the numbers like 83 for a Linux partition. No disk-identifying numbers.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Guest section DW]

On Wed, May 16, 2001 at 09:35:09PM -0400, Jeff Garzik wrote:

> To inject a bit of concrete into this discussion, I note that block
> devices with dynamically assigned don't work with CONFIG_DEVFS and
> devfs=only.  Block devices -require- majors currently, due to those
> !@#!@# arrays.  However, devfs_register_blkdev always returns zero when
> devfs=only, even if its a block device and a dynamic major is requested.

Jeff, this is a non-issue.
These arrays you talk about are removed in a simple edit session -
I did it a handful of times - there is no problem there whatsoever.

What you are talking about is kernel-internal. We are free to do
whatever we like inside the kernel, and we have full information.
The only question is how to transmit device identity across the
kernel space/user space boundary.

Andries


[And my solution is to use cookies - 64-bit opaque numbers that
carry no information, and are generated at random by the kernel,
but with the properties: (i) things that have a device number
today keep this number, (ii) the random generation is such that
whenever possible chances are good that after a reboot the same
device will have the same number.]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Andries . Brouwer]

> I disagree that the kernel should apply sequence numbers

You did not read my text. I do not propose the kernel should.
(Quite the contrary, in fact.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Geert Uytterhoeven]

On Thu, 17 May 2001, Alan Cox wrote:
> > > USB disks are required (haha etc) to have serial numbers. Firewire similarly
> > > has unique disk identifiers.
> > 
> > How about for other device classes?
> 
> Keyboards and mice dont which is a real pig because it prevents you using
> dual head, two usb keyboards and 2 usb mice for a dual user box (assuming
> someone fixed the console code mess to cope with multiple console users as
> a concept)

FYI... http://sf.net/projects/linuxconsole/

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Pavel Machek]

Hi!

> First of all, I apologize for not having sent this notice out sooner. 
> This kind of writing is very painful to deal with.
> 
> Linus Torvalds has requested a moratorium on new device number
> assignments. His hope is that a new and better method for device space
> handing will emerge as a result.

Linus, Is that wise? I could understand moratorium during 2.5, but during 2.4?!

And worse, what about drivers that want to be merged into 2.2?
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Thomas Sailer]

"H. Peter Anvin" schrieb:

> How about for other device classes?

Cheap USB devices (and sometimes even expensive ones)
do not have serial numbers or other unique identifiers.
Therefore some sort of topology based addressing scheme
has to be used in that case.

Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Albert D. Cahalan]

Heinz J. Mauelshag writes:

> LVM does a similar thing storing UUIDs in its private metadata
> area on every device used by it.
>
> Problem is: neither MD nor LVM define a standard in Linux
> which *needs* to be used on every device!
>
> It is just up to the user to configure devices with them or not.
>
> BTW: in case we had a Linux standard it wouldn't solve the
> "different OS" situation mentioned in this thread either.
>
>
> Generally speaking:
> 
> It is not the problem to reserve some space to store a uuid or
> something at such and such location on a device.
>
> The problem is the lack of a standard which eventually
> could be implemented in all OSes at some point in time.

The PC partition table has such an ID. The LILO change log
mentions it. I think it's 6 random bytes, with some restriction
about being non-zero.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Albert D. Cahalan]

Heinz J. Mauelshag writes:

 LVM does a similar thing storing UUIDs in its private metadata
 area on every device used by it.

 Problem is: neither MD nor LVM define a standard in Linux
 which *needs* to be used on every device!

 It is just up to the user to configure devices with them or not.

 BTW: in case we had a Linux standard it wouldn't solve the
 different OS situation mentioned in this thread either.


 Generally speaking:
 
 It is not the problem to reserve some space to store a uuid or
 something at such and such location on a device.

 The problem is the lack of a standard which eventually
 could be implemented in all OSes at some point in time.

The PC partition table has such an ID. The LILO change log
mentions it. I think it's 6 random bytes, with some restriction
about being non-zero.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Thomas Sailer]

H. Peter Anvin schrieb:

 How about for other device classes?

Cheap USB devices (and sometimes even expensive ones)
do not have serial numbers or other unique identifiers.
Therefore some sort of topology based addressing scheme
has to be used in that case.

Tom
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Geert Uytterhoeven]

On Thu, 17 May 2001, Alan Cox wrote:
   USB disks are required (haha etc) to have serial numbers. Firewire similarly
   has unique disk identifiers.
  
  How about for other device classes?
 
 Keyboards and mice dont which is a real pig because it prevents you using
 dual head, two usb keyboards and 2 usb mice for a dual user box (assuming
 someone fixed the console code mess to cope with multiple console users as
 a concept)

FYI... http://sf.net/projects/linuxconsole/

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Andries . Brouwer]

 I disagree that the kernel should apply sequence numbers

You did not read my text. I do not propose the kernel should.
(Quite the contrary, in fact.)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Guest section DW]

On Wed, May 16, 2001 at 09:35:09PM -0400, Jeff Garzik wrote:

 To inject a bit of concrete into this discussion, I note that block
 devices with dynamically assigned don't work with CONFIG_DEVFS and
 devfs=only.  Block devices -require- majors currently, due to those
 !@#!@# arrays.  However, devfs_register_blkdev always returns zero when
 devfs=only, even if its a block device and a dynamic major is requested.

Jeff, this is a non-issue.
These arrays you talk about are removed in a simple edit session -
I did it a handful of times - there is no problem there whatsoever.

What you are talking about is kernel-internal. We are free to do
whatever we like inside the kernel, and we have full information.
The only question is how to transmit device identity across the
kernel space/user space boundary.

Andries


[And my solution is to use cookies - 64-bit opaque numbers that
carry no information, and are generated at random by the kernel,
but with the properties: (i) things that have a device number
today keep this number, (ii) the random generation is such that
whenever possible chances are good that after a reboot the same
device will have the same number.]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Guest section DW]

On Thu, May 17, 2001 at 02:35:55AM -0400, Albert D. Cahalan wrote:

 The PC partition table has such an ID. The LILO change log
 mentions it. I think it's 6 random bytes, with some restriction
 about being non-zero.

You are confused. The partition table contains IDs, but these are
the numbers like 83 for a Linux partition. No disk-identifying numbers.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Michael Meissner]

On Thu, May 17, 2001 at 04:46:33AM +0200, Willem Konynenberg wrote:
 I think here we might learn from the comments that people made
 about how AIX and OSF/1/Tru64 have been doing this.

However, I suspect that generally AIX and OSF/1 Tru64 systems come with system
managers.  Many Linux system do not (well presumably anybody who reads this
mailing list has enough of a clue).  Also, I bet the number of USB and
Firewire devices used on the above two systems is probably vanishingly small.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Alan Cox]

 Linus, Is that wise? I could understand moratorium during 2.5, but during 2.4?!
 And worse, what about drivers that want to be merged into 2.2?

2.2 will be using the same forked registry as 2.4-ac. I dont anticipate much
being added to it that will need a major however

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Oliver Neukum]

 Since, as Alan mentioned, the lack of device serial numbers for USB mice
 and keyboards means that the only way to implement a relatively stable
 assignment of USB input devices to a quasi-multiuser system with
 multi-headed displays is by paying attention to USB topology, I would
 like us to explore any implementation that includes this support.  As
 Linus mentioned, this approach is unreliable, but it's all we have for
 these devices -- Topology can be disturbed by a variety of events
 (plugging a hub into a different host-controller port, etc).

For identifying this is probably the right approach. However identifying is 
not enough, as the ioctl discussion has shown. Capabilities are needed. How 
can the device registry provide that information ? If we register it together 
with the device, we might spend a lot of resources needlessly and can't deal 
with devices whose capabilities change dynamically.

In addition how do we export the information ? Proc ? Device nodes (bad for 
network devices) ?

Regards
Oliver
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[David Brownell]

  At this point of the discussion I would like to point to the Device Registry 
  patch (http://www.tjansen.de/devreg) that already solves these problems and 
  offers stable device ids for the identification of devices and finding their 
  /dev nodes.
  
  The devreg device id has four components: the bus identifier, the location of 
  the device (for pci bus number and slot number, for usb the bus number and a 
  list of port numbers), a model (product and device id) and, if available, a 
  serial number. 
 
 Hmm.  It's interesting to me that there have been no replies discussing
 Tim's code.  

I'd want to put it in the context of some of the USB work already done,
and also know how it generalizes to other busses ... 

For example, that usb-devname patch of mine, posted to linux-usb-devel
somewhere around 12/6/2000 (2.4.0-test12), which worked the issue
of teaching USB about stable identifiers (like pci slot_name, except
it didn't address functions within device configurations since PCI doesn't
have that notion of configuration).

Or the patch providing a standard API for USB device drivers to report
what major/minor device numbers are associated with a given interface
(I think it was Alan Barnett who provided that).

Or the original (userspace) XML dump of XML tree structure, shown
at  http://jusb.sourceforge.net/?selected=tree ... it's not clear to me which
structural information there is also found in the devreg XML syntax
(from the kernel!), and which isn't.  (Class information omitted from
devreg?  Interface structure?)  Most of it's known to be needed.

For example, USB bus numbers are themselves unstable identifiers;
PCI slot_name fields work better, at least for host controllers (most!)
which use PCI.  If devreg uses bus numbers, that needs to change.

- Dave


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[James Simmons]

   USB disks are required (haha etc) to have serial numbers. Firewire similarly
   has unique disk identifiers.
  
  How about for other device classes?
 
 Keyboards and mice dont which is a real pig because it prevents you using
 dual head, two usb keyboards and 2 usb mice for a dual user box (assuming
 someone fixed the console code mess to cope with multiple console users as
 a concept)

Wrong!! I already have a multi-desktop system running at home. I have two
PS/2 keyboards, Sun keyboard, and a USB keyboard hooked up to my system. I
only have two monitors/video cards so I only have two VTs going at the
same time. I even managed to get two X servers running on each VT
independent of each other. This was not ease but it is possible. 
   I can tell you I didn't use any type of id system. How do I deal with
devices like multiple sound cards (yes I have that too) in a multidesktop
environment? With file permission on the device nodes. I created
different groups for different desktops. With a little tweaking with PAM
when I login to a specific workstation I'm automatically added to a
certain desktop group. I can't access any devices that belong to another 
desktop group. When I logout I'm removed from that group. Now xdm needs a
little hacking to make this work. 
   The beauty of this approach is the admin determines which devices
belong to which desktop. Now for hotpluggable devices when they plugged
back in a device they just unplugged and they don't end up on the same
device that new device will belong to no one. They can use some userland
utility then to grab the device. In this case it is first come first
serve. Surely when you plug in your device you are NOT going to steal a
device in use but one that is avaliable. Now what if two people unplug
their mice at the same time and plug them back in and they are mixed up.
Again I think a userland utility can solve this problem. Here you would
need to be root to fix the problem. 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Tim Jansen]

On Thursday 17 May 2001 14:07, you wrote:
 For identifying this is probably the right approach. However identifying is
 not enough, as the ioctl discussion has shown. Capabilities are needed. How
 can the device registry provide that information ? 

The device registry provides you with device's capabilities and has different 
meachanisms for different needs:

- each device node has a type that describes the API (read/write format, 
ioctls) of the node. The type is set when you call devfs_register2 (a new 
version of devfs_register, set sets the node type and a connection to the 
physical device). So when you want to play pcm sound and your app supports 
OSS you search for the type sound/oss/dsp
- each physical device gets a type that is intended to be shown to the user 
and may be simplified. It can be used for things like selecting a appropriate 
icon for a device. It is not guaranteed to be correctly and some devices may 
not have a type.
- each bus subsystem and driver is free to add its own information. For 
example the PCI subsystem adds things like the interrupt, memory space and so 
on. User-space apps that dont know about it are required to ignore it. 


 If we register it together with the device, we might spend a lot of 
 resources needlessly and can't deal with devices whose capabilities 
 change dynamically.

No, the device and bus-subsystem information is generated on-demand, the type 
isnt guaranteed to be correct (and can be changed at any time) and the API of 
your device nodes hopefully doesnt change or otherwise you will really 
confuse the apps.


 In addition how do we export the information ? Proc ? Device nodes (bad for
 network devices) ?

The last version used a large XML file, but the next will expose the 
information in a (very) large number of proc files, each containing a single 
value. This required some changes in the proc API, but unfortunately I did 
not get a single comment on my patch 
(http://www.uwsg.indiana.edu/hypermail/linux/kernel/0105.1/1041.html)..

bye...

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Tim Jansen]

On Thursday 17 May 2001 08:43, Thomas Sailer wrote:
 Cheap USB devices (and sometimes even expensive ones)
 do not have serial numbers or other unique identifiers.
 Therefore some sort of topology based addressing scheme
 has to be used in that case.

No, there is another addressing scheme that can be for devices without serial 
number: the vendor and product ids. Most people do not have two devices of 
the same kind, so you often do not need the topology at all.

BTW this document describes the use of device ids on windows:
http://www.osr.com/ddk/idstrings_8tt3.htm

bye...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[James Simmons]

 Hmm.  It's interesting to me that there have been no replies discussing
 Tim's code.  Are any of you looking at it or do you simply think it is
 inconsequential and deserves to be ignored?
 Or, perhaps folks feel that it is off-topic?

Haven't had the chance to look at it. This weekend I will take a look.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[David Brownell]

 For identifying this is probably the right approach. However identifying is 
 not enough, as the ioctl discussion has shown. Capabilities are needed. How 
 can the device registry provide that information ? 

My feedback on device registry 0.1 was that I really liked the
approach of _modeling_ devices by attributes ... which reminded me
of the good things in attribute based naming a la X.500/LDAP
models.  I suspect 0.2 went too far, using XML to expose those
attributes to userspace ... :)

If each device had a directory node, those directory nodes could be
grouped as a registry ... the directory contents would list the various
bus-specific or type-specific capabilities/attributes.  Would those
directory nodes be the /dev/... or /devfs/... nodes?  I suspect not.


If we register it together 
 with the device, we might spend a lot of resources needlessly and can't deal 
 with devices whose capabilities change dynamically.

So obviously such a registry should query the drivers/busses directly.


 In addition how do we export the information ? Proc ?

I think Tim has some ideas here, given a patch I scanned recently...

- Dave


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Eric W. Biederman]

Daniel Phillips [EMAIL PROTECTED] writes:

 On Tuesday 15 May 2001 23:20, Nicolas Pitre wrote:
  Personally, I'd really like to see /dev/ttyS0 be the first detected
  serial port on a system, /dev/ttyS1 the second, etc.
 
 There are well-defined rules for the first four on PC's.  The ttySx 
 better match the labels the OEM put on the box.

Actually it would be better to have the OEM put a label in the
firmware, and then have a way to query the device for it's label.

The legacy rules are nice but serial ports are done with superio chips
now.  And superio chips are almost all ISA PNP chips without device
enumeration, and isolation. 

Eric

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/