Andrzej Krzysztofowicz writes:
> >
> > OK, just correct me if I get this wrong, but this code is taking the LAST 2
> > characters of the device name and verifying that it is "cd". Which would
> > mean that the standard states that "/dev/ginsucd" would be a CD-ROM drive?
> >
> > That is why I fe
[EMAIL PROTECTED] (Hacksaw) writes:
> >So what is your solution for preventing a boot failure after disks/partitions
> >change ?
> >volume labels/UUID ?
>
> As a sys-admin, let me add a vote for this. Having (one day) a prom monitor
> program that looks at all the disks, and gives a menu of whi
> mmap is fine for a fb, but please don't remove read/write.
> I can now do a screendump with "cat /dev/fb/0 > file",
> because everything is a file.
> Having
> /dev/fb/0/brightness
> /dev/fb/0/opengl
> and so on seems to be a better approach.
One I like to name of the file system to be someth
>So what is your solution for preventing a boot failure after disks/partitions
>change ?
>volume labels/UUID ?
As a sys-admin, let me add a vote for this. Having (one day) a prom monitor
program that looks at all the disks, and gives a menu of which one to boot
from would make life so nice.
I
On Wed, May 16, 2001 at 02:09:32PM +0200, Thomas Kotzian wrote:
> From: "Helge Hafting" <[EMAIL PROTECTED]>
> > Partition id's seems more interesting than disk id's - we normally
> > mount partitions not whole disks.
> >
> > RAID do this well - the raid autodetect partition stores an ID in the
> >
> > 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.
>
> Does your approach solve the pr
On Tue, May 15, 2001 at 01:18:09PM -0700, Linus Torvalds wrote:
>
> On Tue, 15 May 2001, Jonathan Lundell wrote:
> > >
> > >Keep it informational. And NEVER EVER make it part of the design.
> >
> > What about:
> >
> > 1 (network domain). I have two network interfaces that I connect to
> > two
On Wed, May 16, 2001 at 09:30:46AM -0700, Miles Lane wrote:
> On 16 May 2001 15:28:03 +0200, Helge Hafting wrote:
> > Oystein Viggen wrote:
> > >
> > > Quoth Helge Hafting:
> > >
> > > > This could be extended to non-raid use - i.e. use the "raid autodetect"
> > > > partition type for non-raid a
On 16 May 2001 15:28:03 +0200, Helge Hafting wrote:
> Oystein Viggen wrote:
> >
> > Quoth Helge Hafting:
> >
> > > This could be extended to non-raid use - i.e. use the "raid autodetect"
> > > partition type for non-raid as well. The autodetect routine could
> > > then create /dev/partitions/ho
Hi HPA, Linus, Alan,
On Mon, May 14, 2001 at 12:19:34PM -0700, H. Peter Anvin wrote:
> 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.
>
> Alan Cox has requested that I main
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yesterday, Timothy A. Seufert ([EMAIL PROTECTED]) wrote:
> Why not take it a step further than just devices? This is a perfect
> model for supporting named forks.
Because this only works on filesystems where directories can't themselves
have na
At 4:57 PM +0200 2001-05-16, Vojtech Pavlik wrote:
>On Wed, May 16, 2001 at 07:37:45AM -0700, Jonathan Lundell wrote:
>> At 10:02 AM +0200 2001-05-16, Vojtech Pavlik wrote:
>> > > It's also true that some buses simply don't yield up physical
>> >> locations (ISA springs to mind,
>> >
>> >I
At 11:56 AM +0200 2001-05-16, Chemolli Francesco (USI) wrote:
>We could do something like baptizing disks.. Fix some location
>(i.e. the absolutely last sector of the disk or the partition table or
>whatever) and store there some 32-bit ID
>(could be a random number, a progressive number, whatever
Well, even if you spank the future violators, what about the current
overlaps?
E.g., the CD-ROM ioctls are overlapping
with the STREAMS ioctls (the latter ones used by LiS and honored by glibc).
V.
> -Original Message-
> From: H. Peter Anvin [mailto:[EMAIL PROTECTED]]
> Alan Cox wrote:
>
On Wed, May 16, 2001 at 07:37:45AM -0700, Jonathan Lundell wrote:
> At 10:02 AM +0200 2001-05-16, Vojtech Pavlik wrote:
> > > It's also true that some buses simply don't yield up physical
> >> locations (ISA springs to mind,
> >
> >ISA is quite fine, you can use the i/o space as physical locati
At 10:02 AM +0200 2001-05-16, Vojtech Pavlik wrote:
> > It's also true that some buses simply don't yield up physical
>> locations (ISA springs to mind,
>
>ISA is quite fine, you can use the i/o space as physical locations.
I meant physical not as in physical-vs-virtual addresses (all ISA
add
Oystein Viggen wrote:
>
> Quoth Helge Hafting:
>
> > This could be extended to non-raid use - i.e. use the "raid autodetect"
> > partition type for non-raid as well. The autodetect routine could
> > then create /dev/partitions/home, /dev/partitions/usr or
> > /dev/partitions/name_of_my_choice
>
> 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 h
Bob Glamm <[EMAIL PROTECTED]>:
> Finally, there has to be an *easy* way of identifying devices from software.
> You're right, I don't care if my network cards are numbered 0-1-2, 2-0-1,
> or in any other permutation, *as long as I can write something like this*:
>
> # start up networking
> f
On Wed, May 16 2001, Daniel Phillips wrote:
> On Tuesday 15 May 2001 17:34, Linus Torvalds wrote:
> > On Tue, 15 May 2001, Neil Brown wrote:
> > > Ofcourse setting the "queue" function that __blk_get_queue call to
> > > do a lookup of the minor and choose an appropriate queue for the
> > > "real"
Oystein Viggen wrote:
> What happens if I insert a hard drive from another computer which also
> has partitions named "home", "usr", and soforth?
not to belabor the obvious, but there are a lot of issues with this
particular approach.
for those who advocate writing some form of signature into
On Tue, 15 May 2001, Jonathan Lundell wrote:
> >The 2.4 kernel allows you to rename an interface. So you can build
> >a little database of (MAC address/name) pairs. Apply this after booting
> >and before bringing up the interfaces and everything has the name
> >you wanted, based on MAC address.
Quoth Helge Hafting:
> This could be extended to non-raid use - i.e. use the "raid autodetect"
> partition type for non-raid as well. The autodetect routine could
> then create /dev/partitions/home, /dev/partitions/usr or
> /dev/partitions/name_of_my_choice
> for autodetect partitions not parti
From: "Helge Hafting" <[EMAIL PROTECTED]>
> Partition id's seems more interesting than disk id's - we normally
> mount partitions not whole disks.
>
> RAID do this well - the raid autodetect partition stores an ID in the
> last block,
> the remaining N-1 blocks are available for a fs.
>
> This cou
On Wed, May 16, 2001 at 02:59:30AM +0200, Daniel Phillips wrote:
> 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 fou
"Chemolli Francesco (USI)" wrote:
>
> > The argument that "if you use numbering based on where in the
> > SCSI chain
> > the disk is, disks don't pop in and out" is absolute crap.
> > It's not true
> > even for SCSI any more (there are devices that will aquire
> > their location
> > dynamically),
> I believe thats why there are persistant superblocks on the RAID
> partitions. You can switch them around, and it still knows which drive
> holds which RAID partition... That's the only way booting off RAID
> works, and the only reason for the "RAID Autodetect" partition type...
> you can find
> The argument that "if you use numbering based on where in the
> SCSI chain
> the disk is, disks don't pop in and out" is absolute crap.
> It's not true
> even for SCSI any more (there are devices that will aquire
> their location
> dynamically), and it has never been true anywhere else. Give
Alexander Viro writes:
> thing, we could turn mount(2) into
> open appropriate fs type
> convince the sucker that you are allowed, tell which device you want,
> etc.
> open mountpoint
> mount(fs_fd, dir_fd)
> Would work like charm, especially since we could fit the network
On Mon, May 14, 2001 at 09:33:35PM -0300, Rik van Riel wrote:
> Agreed. However, if this thing means I cannot use the -linus
> tree without devfs, then it will also mean my VM stuff only
> gets tested on -ac kernels...
No Problem. I test most of your VM stuff anyway and I use devfs
on that machin
Johannes Erdfelt wrote:
> 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.
You could have "open("/ipv4/127.0.0.1/80") wit
James Simmons wrote:
>
> > > I would use write except we use write to draw into the framebuffer. If I
> > > write to the framebuffer with that data the only thing that will happen is
> > > I will get pretty colors on my screen.
> >
> > Yes. And we also use write to send data to printer. So what?
On Tue, May 15, 2001 at 11:56:41PM -0700, Jonathan Lundell wrote:
> At 12:31 PM +1000 2001-05-16, Andrew Morton wrote:
> > > When I ifconfig one of a collection of interfaces, I'm very much
> >> talking about the specific physical interface connected via a
> > > specific physical cable to a spe
On 16 May 2001, Kai Henningsen wrote:
> [EMAIL PROTECTED] (H. Peter Anvin) wrote on 15.05.01 in
><[EMAIL PROTECTED]>:
>
> > Personally, I would also like to see network devices manifest in the
> > filesystem namespace like everything else.
>
> Yes.
>
> Can we have a meta-rule?
>
> *Every*
>
> OK, just correct me if I get this wrong, but this code is taking the LAST 2
> characters of the device name and verifying that it is "cd". Which would
> mean that the standard states that "/dev/ginsucd" would be a CD-ROM drive?
>
> That is why I feel a "name" of a device handle shouldnt set
On Tue, 15 May 2001, Jeff Garzik wrote:
> Linus Torvalds wrote:
> > Now, if we just fundamentally try to think about any device as being
> > hot-pluggable, you realize that things like "which PCI slot is this device
> > in" are completely _worthless_ as device identification, because they
> > fund
On Tue, 15 May 2001, Linus Torvalds wrote:
> On Tue, 15 May 2001, Jonathan Lundell wrote:
> > 2 (disk domain). I have multiple spindles on multiple SCSI adapters.
>
> So? Same deal. You don't have eth0..N, you have disk0..N.
>
> What's the problem? It's _repeatable_, in that as long as you don
[EMAIL PROTECTED] (James Simmons) wrote on 15.05.01 in
<[EMAIL PROTECTED]>:
> > > I couldn't agree with you more. It gives me headaches at work. One note,
> > > their is a except to the eth0 thing. USB to USB networking. It uses
> > > usb0, etc. I personally which they use eth0.
> >
> > USB to
[EMAIL PROTECTED] (H. Peter Anvin) wrote on 15.05.01 in
<[EMAIL PROTECTED]>:
> Personally, I would also like to see network devices manifest in the
> filesystem namespace like everything else.
Yes.
Can we have a meta-rule?
*Every* by-name kernel interface should have a filesystem variant.
T
On Tue, 15 May 2001, Richard Gooch wrote:
> Alan Cox writes:
> > > len = readlink ("/proc/self/3", buffer, buflen);
> > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > > exit (1);
> >
> > And on my box cd is the cabb
[EMAIL PROTECTED] (Daniel Phillips) wrote on 16.05.01 in
<01051602593001.00406@starship>:
> 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-defi
On Tue, 15 May 2001, Timothy A. Seufert wrote:
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >On Tue, 15 May 2001, Alexander Viro wrote:
> >> Driver can export a tree and we mount it on fb0. After that you have
> >> the whole set - yes, /dev/fb0/colourspace, etc. - no problem. And no
> >> need to
At 12:31 PM +1000 2001-05-16, Andrew Morton wrote:
> > When I ifconfig one of a collection of interfaces, I'm very much
>> talking about the specific physical interface connected via a
> > specific physical cable to a specific physical switch port.
>>
>
>Yes, it can be a security trap as well -
Miles Lane <[EMAIL PROTECTED]> wrote on 15/5/01 17:41:
>Does your approach solve
>the problem of USB devices,
>like mice, that
>don't have device ID's of any
>sort, where topology is the
>only way to
>distinguish them?
yes, that's what the location part is for.
Bye...
-
To unsubscribe f
On Tuesday May 15, [EMAIL PROTECTED] wrote:
>
> On Tue, 15 May 2001, Neil Brown wrote:
> >
> > Ofcourse setting the "queue" function that __blk_get_queue call to do
> > a lookup of the minor and choose an appropriate queue for the "real"
> > device wont work as you need to munge bh->b_rdev too.
Jonathan Lundell wrote:
>
> ...
> I *like* eth0..n (I'd like net0..n better). And I *can't* ask what
> eth0 and eth1 are, by the way, but I should be able to (Jeff Garzik
> has proposed an extension to ethtool to help out this lack, but it's
> not in Linux today, and needs concrete implementation
At 9:34 PM -0400 2001-05-15, Nicolas Pitre wrote:
>On Wed, 16 May 2001, Daniel Phillips wrote:
>
>> 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
On Wed, 16 May 2001, Daniel Phillips wrote:
> 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 tty
Daniel Phillips wrote:
>
> Sounds like "treat it like a file and it acts like a file, treat it
> like a directory and it acts like a directory".
>
The original plan was that you only could indirect through it; not
chdir() for example. One could do the whole enchilada, but then one
would have t
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.
--
On Tuesday 15 May 2001 22:51, Linus Torvalds wrote:
> On Tue, 15 May 2001, Alexander Viro wrote:
> > If you want them all to inherit it - inherit from mountpoint.
>
> ..which is exactly what the device node ends up being. The implicit
> mount-point.
>
> And which point, btw, it is completely indis
On Tuesday 15 May 2001 17:34, Linus Torvalds wrote:
> On Tue, 15 May 2001, Neil Brown wrote:
> > Ofcourse setting the "queue" function that __blk_get_queue call to
> > do a lookup of the minor and choose an appropriate queue for the
> > "real" device wont work as you need to munge bh->b_rdev too.
At 1:18 PM -0700 2001-05-15, Linus Torvalds wrote:
> > 1 (network domain). I have two network interfaces that I connect to
>> two different network segments, eth0 & eth1;
>
>So?
>
>Informational. You can always ask what "eth0" and "eth1" are.
>
>There's another side to this: repeatability. A set
On 16 May 2001 01:56:23 +0200, Tim Jansen wrote:
> On Wednesday 16 May 2001 01:16, David Brownell wrote:
> >Only if it's augmented by additional device IDs, such as the
> >"what 's the physical connection for this interface" sort of
> >primitive that's been mentioned.
> >[...]
> > I suppose that f
At 4:35 PM -0700 2001-05-15, David Brownell wrote:
>[ Re why "physical" device IDs _should_ have a critical role in sysadmin ]
>
>> I would have to agree that "stable" is critical to not driving people
>> crazy. In the case of AIX, once a device is enumerated, it will retain
>> the same name a
> > I suppose that for network interface names, some convention for
> > interface ioctls would suffice to solve that "identify" step. PCI
> > devices would return the slot_name, USB devices need something
> > like a patch I posted to linux-usb-devel a few months back.
>
> This is crap.
Only the
CTED]]
Sent: Tuesday, May 15, 2001 11:30 AM
To: Linus Torvalds; Jonathan Lundell
Cc: Jeff Garzik; James Simmons; Alan Cox; Neil Brown; H. Peter Anvin;
Linux Kernel Mailing List; [EMAIL PROTECTED]; Alex Bligh - linux-kernel
Subject: Re: LANANA: To Pending Device Number Registrants
> The ar
On Wednesday 16 May 2001 01:16, David Brownell wrote:
>Only if it's augmented by additional device IDs, such as the
>"what 's the physical connection for this interface" sort of
>primitive that's been mentioned.
>[...]
> I suppose that for network interface names, some convention for
> interface i
OK, just correct me if I get this wrong, but this code is taking the LAST 2
characters of the device name and verifying that it is "cd". Which would
mean that the standard states that "/dev/ginsucd" would be a CD-ROM drive?
That is why I feel a "name" of a device handle shouldnt set how a driver
According to Alan Cox:
> Chip:
> > Wouldn't it be better just to *try* ioctls and see which ones work and
> > which ones don't?
>
> 1. We have overlaps
We all agree that overlaps need to be eliminated over time. In the
meantime, as a coping strategy: I'll bet you that for any two given
device c
On Tue, 15 May 2001, David Brownell wrote:
> I suppose that for network interface names, some convention for
> interface ioctls would suffice to solve that "identify" step. PCI
> devices would return the slot_name, USB devices need something
> like a patch I posted to linux-usb-devel a few mon
[ Re why "physical" device IDs _should_ have a critical role in sysadmin ]
> I would have to agree that "stable" is critical to not driving people
> crazy. In the case of AIX, once a device is enumerated, it will retain
> the same name across reboots. Enough information is kept about each
> dev
Chip Salzenberg wrote:
> According to Alan Cox:
> > Given a file handle 'X' how do I find out what ioctl groups I should
> > apply to it.
>
> Wouldn't it be better just to *try* ioctls and see which ones work and
> which ones don't?
As ioctl's is just numbers that can be valid but mean totally d
> > The "eth0..N" naming is done RIGHT!
Only if it's augmented by additional device IDs, such as the
"what 's the physical connection for this interface" sort of
primitive that's been mentioned.
> Nothing to do with the kernel but, one should then argue that the
> current stuff in /etc/syscon
David Bronwell writes:
> Linus writes:
> > Now, if we just fundamentally try to think about any device as being
> > hot-pluggable, you realize that things like "which PCI slot is this device
> > in" are completely _worthless_ as device identification, because they
> > fundamentally take the wro
> > Graphics cards are the same way. Especially high end ones. They have pipes
> > as well. For low end cards you can think of them as single pipeline cards
> > with one pipe.
>
> It still frosts my shorts that DRM (e.g. /dev/dri/card0) doesn't use
> write(). It's a natural way to feed pipeline
> According to Alan Cox:
> > Given a file handle 'X' how do I find out what ioctl groups I should
> > apply to it.
>
> Wouldn't it be better just to *try* ioctls and see which ones work and
> which ones don't?
You can do this with the tty layer. Just open /dev/tty and try tioclinux.
On my seri
> > > I couldn't agree with you more. It gives me headaches at work. One note,
> > > their is a except to the eth0 thing. USB to USB networking. It uses usb0,
> > > etc. I personally which they use eth0.
> >
> > USB to USB networking cables aren't ethernet.
>
> I'm talking about a wireless co
Alex Bligh writes:
> Q: Let us assume you have dynamic numbering disk0..N as you suggest,
>and you have some s/w RAID of SCSI disks. A disk fails, and is (hot)
>removed. Life continues. You reboot the machine. Disks are now numbered
>disk0..(N-1). If the RAID config specifies using dis
Alan Cox wrote:
>
> > 1. is of course a problem in itself. Someone who creates overlapping
> > ioctls should be spanked, hard.
>
> No argument there. But there is no LANANA ioctl body
>
I though Michael Chastain was maintaining this set. No, we haven't made
it an official LANANA function, mo
> Even if we have per-device filesystems, we are going to have the same
> issue, in one form or another. If we have a "/devicetype" trailing
> component added on, then somewhere it has to report "CD-ROM" or "cd"
> or "Compact Disc".
When I ask it. Not when I name it
-
To unsubscribe from this lis
On Tue, 15 May 2001, Richard Gooch wrote:
> Me&Linus. The device name authority (Peter). Whoever. If you want
> Peter to bless it, then fine. But the standard is there. Violators
> will be persecuted.
Ah, standard on names in devfs? About as relevant as GOSIP...
-
To unsubscribe from this lis
> > >Keep it informational. And NEVER EVER make it part of the design.
> >
> > What about:
> >
> > 1 (network domain). I have two network interfaces that I connect to
> > two different network segments, eth0 & eth1;
>
> So?
>
> Informational. You can always ask what "eth0" and "eth1" are.
[..
Richard Gooch wrote:
>
> Even if we have per-device filesystems, we are going to have the same
> issue, in one form or another. If we have a "/devicetype" trailing
> component added on, then somewhere it has to report "CD-ROM" or "cd"
> or "Compact Disc".
>
Again, many device types aren't mutua
> 1. is of course a problem in itself. Someone who creates overlapping
> ioctls should be spanked, hard.
No argument there. But there is no LANANA ioctl body
> Agreed, but "determining type of device" and "determining if interface X
> is available on this device" are different operations. If t
> And my opinion is that the "hot-plugged" approach works for devices even
> if they are soldered down ...
Yep. Though I tend to look at the whole problem as "autoconfiguration"
lately. Solving device naming (even the major/minor subproblem) is only
one part of having a complete autoconfigurat
Alan Cox writes:
> > > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > > > exit (1);
> > >
> > > And on my box cd is the cabbage dicer whoops
> >
> > Actually, no, because it's guaranteed that a tr
Richard Gooch wrote:
>
> Alexander Viro writes:
> >
> >
> > On Tue, 15 May 2001, Richard Gooch wrote:
> >
> > > Alan Cox writes:
> > > > > len = readlink ("/proc/self/3", buffer, buflen);
> > > > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > > > fprintf (stde
Alexander Viro writes:
>
>
> On Tue, 15 May 2001, Richard Gooch wrote:
>
> > Alan Cox writes:
> > > > len = readlink ("/proc/self/3", buffer, buflen);
> > > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> >
> Type of filesystem where the file came from? Sure.
Who says it comes from only one - even on devfs that is not true
/dev/disk/4 is quite possibly
disk
scsi-disk
scsi-device
usb-scsi-device
usb-device
all at once
-
To unsubscribe from this list: send t
> > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > > exit (1);
> >
> > And on my box cd is the cabbage dicer whoops
>
> Actually, no, because it's guaranteed that a trailing "/cd" is a
> CD-ROM. That's the standard.
Alan Cox wrote:
>
> > Wouldn't it be better just to *try* ioctls and see which ones work and
> > which ones don't?
>
> 1. We have overlaps
>
1. is of course a problem in itself. Someone who creates overlapping
ioctls should be spanked, hard.
> 2. I've seen code where people play clever ioctl
> Wouldn't it be better just to *try* ioctls and see which ones work and
> which ones don't?
1. We have overlaps
2. I've seen code where people play clever ioctl tricks to deduce a device
type and it ends up looking like one of those chemistry identification
charts (hopefully minus do you see sm
> I couldn't agree with you more. It gives me headaches at work. One note,
> their is a except to the eth0 thing. USB to USB networking. It uses usb0,
> etc. I personally which they use eth0.
>
The packet framing is quite different so it doesnt really make sense. For
wireless it does use ether
On 15 May 2001 13:26:58 -0700, Dan Hollis wrote:
> This thread is becoming high enough volume and likely to become much more
> so, perhaps a separate ml should be set up for it? linux-device-management
> perhaps?
I agree that this is going to be a very high-volume discussion. OTOH,
this discussi
Chip Salzenberg wrote:
>
> According to H. Peter Anvin:
> > A device can inherently belong to multiple device classes, and it
> > really should be thought of as such.
>
> And then there are layering technologies like LVM and loopback.
> They should be included in a discovery, but if you limit yo
According to H. Peter Anvin:
> A device can inherently belong to multiple device classes, and it
> really should be thought of as such.
And then there are layering technologies like LVM and loopback.
They should be included in a discovery, but if you limit yourself
to one "device type", there's n
According to James Simmons:
> Graphics cards are the same way. Especially high end ones. They have pipes
> as well. For low end cards you can think of them as single pipeline cards
> with one pipe.
It still frosts my shorts that DRM (e.g. /dev/dri/card0) doesn't use
write(). It's a natural way t
According to Johannes Erdfelt:
> 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.
I think you're right on both counts, but
Alexander Viro wrote:
>
> On Tue, 15 May 2001, Chip Salzenberg wrote:
>
> > According to Linus Torvalds:
> > > I don't see why we couldn't expose the "driver name" for any file
> > > descriptor.
> >
> > Is it wise to assume that there is only one such name for *any* file
> > descriptor?
>
> Typ
On Tue, May 15, 2001 at 10:29:38PM +0100, Alex Bligh - linux-kernel wrote:
> > The argument that "if you use numbering based on where in the SCSI chain
> > the disk is, disks don't pop in and out" is absolute crap. It's not true
> > even for SCSI any more (there are devices that will aquire their
> > Yes. And we also use write to send data to printer. So what? Nobody makes
> > you use the same file.
>
> You're talking about /dev/fb0 vs. /dev/fb0ctl, right?
No. We are talking about a fbdev filesystem versus what we have now.
See later in the thread.
-
To unsubscribe from this list: send
> > I couldn't agree with you more. It gives me headaches at work. One note,
> > their is a except to the eth0 thing. USB to USB networking. It uses usb0,
> > etc. I personally which they use eth0.
>
> USB to USB networking cables aren't ethernet.
I'm talking about a wireless connection. ipaq
Linus Torvalds <[EMAIL PROTECTED]> [01/05/15 16:28]:
>
> The "eth0..N" naming is done RIGHT!
Nothing to do with the kernel but, one should then argue that the
current stuff in /etc/sysconfig/network-scripts is broken for hotplug as
placing a new network adapter into your bus will renumber your i
Linus writes:
> And my opinion is that the "hot-plugged" approach works for devices even
> if they are soldered down - the "plugging" event just always happens
> before the OS is booted, and people just don't unplug it. So we might as
> well consider devices to always be hot-pluggable, whether tha
According to Linus Torvalds:
> I don't see why we couldn't expose the "driver name" for any file
> descriptor.
Is it wise to assume that there is only one such name for *any* file
descriptor?
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"We have no fuel on board, p
According to Alexander Viro:
> On Tue, 15 May 2001, James Simmons wrote:
> > I would use write except we use write to draw into the framebuffer. If I
> > write to the framebuffer with that data the only thing that will happen is
> > I will get pretty colors on my screen.
>
> Yes. And we also use
On Tue, May 15, 2001, James Simmons <[EMAIL PROTECTED]> wrote:
> > Personally, I'd really like to see /dev/ttyS0 be the first detected serial
> > port on a system, /dev/ttyS1 the second, etc. Currently there are plenty of
> > different serial hardware with all their own drivers and /dev entries.
Alan Cox writes:
> > len = readlink ("/proc/self/3", buffer, buflen);
> > if (strcmp (buffer + len - 2, "cd") != 0) {
> > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > exit (1);
>
> And on my box cd is the cabbage dicer whoops
Actually, no, because it's gua
On Tue, 15 May 2001, Chip Salzenberg wrote:
> According to Linus Torvalds:
> > I don't see why we couldn't expose the "driver name" for any file
> > descriptor.
>
> Is it wise to assume that there is only one such name for *any* file
> descriptor?
Type of filesystem where the file came from?
101 - 200 of 321 matches
Mail list logo
