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,
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
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,
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
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.
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
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
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
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
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
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.
>
>
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
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
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
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
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
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
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
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
>
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
[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
[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
[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
[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
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
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
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
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
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
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
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
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
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
> > 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
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
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
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
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
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
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 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
> > 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
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
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
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).
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
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
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
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
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.
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
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
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
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;
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
[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
[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
[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.
[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 =
[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
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
[ 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
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
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:
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
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
> 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
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
> 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
> 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
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
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
> > > 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
> > 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
> 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
> 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
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
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
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,
> 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
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
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
"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
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
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.
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:
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
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
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,
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
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
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
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
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
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
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
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
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
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_
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
1 - 100 of 634 matches
Mail list logo