Larger dev_t

Aha - after your previous explosion I had concluded that working on *dev_t was useless, but it seems we are still talking.

Let me repeat: there is no such code. In user space dev_t already is 64 bits, whether you like it or not. We cannot go back to libc5.

In kernel space we all want to use pointers to a device struct, and major and minor are fields in that struct. There is no advantage in making those fields narrow. And what is carried around is the pointer, a 32-bit object.

In other words, inside the kernel the normal obvious coding will give us ints major, minor. Outside the kernel we have a 64-bit dev_t. And there is only the interface of system calls that uses this narrow 16-bit straw. Of course, making it 32-bit is an improvement but I can really not see any reason to make things difficult for ourselves by widening this straw to 32-bits only.
Changing kernel and filesystems and glibc is a bit of a hassle - not very difficult, but we started six years ago and still have not finished - so it is better to do things right at once.

It was an example showing the advantage of having a 64-bit object. Code gets simpler and faster.
But while dev_t already is 64-bits in user space, the same does not hold for pid_t. I think that I once sent you a patch that would make the pid use 2^31 instead of 2^15 values. Changing the size of pid_t is not really possible, it would require a new version of the glibc library.

In short, both your arguments are totally bogus. Your "simpler" function is in fact a horrible rats nest and a source of subtle bugs that you apparently never even thought about.

And that's without ever actually mentioning the word "bloat" and "data cache usage".

Not so pessimistic. Think and reconsider.

Andries

Now you're back to the argument that "glibc is bloated, so we might as well be too".

The fact is, that I don't like that argument. I don't buy into that kind of philosophy. If somebody else made a mistake, that doesn't force me to do the same mistake.

Agreed. I'm not worried about that part.

But I have a holy crusade. I dislike waste. I dislike over-engineering. I absolutely detest the "because we can" mentality. I think small is beautiful, and the guildeline should always be that performance and size are more important than features.

I don't see the "difficulty".

The fact is, that there are two uses for dev_t's:
- the "unnamed" ones. Where we've had 8 bits of namespace for ten years, and even now it's only mildly painful (ie most people never notice). We probably don't need more than 10-11 bits in practice (even with automounting on large sites, I doubt you'll find a site that needs to have mroe than a few thousand mounts active at the same time). 20 bits is _plenty_.

- /dev.

And let's take a look at /dev. Do a "ls -l /dev" and think about it. Every device needs a unique number. Do you ever envision seeing that "ls -l" taking about 500 billion years to complete? I don't. I don't think you do. But that's how ludicrous a 64-bit device number is.

So in /dev, there are two problems: we are getting painfully close to major numbers with 8 bits, and we've run out of minors several times. In fact, a lot of the reason for the dearthness of major numbers is the fact that we use multiple majors for some stuff that really wants many minors.

So 8 bits for major is actually fairly close to perfectly livable - or at least would be if we had more minors. And there is no question about
it: you need a lookup table for major numbers. Which means that 32 bits of major numbers is ridiculous. As is 20. Which is why I suggested 12. A nice size, that is reasonable in real life, and that can easily be used for table lookups. It's also sixteen times larger than what we have today, which would probably be acceptable in itself.

For minors, we have the problem of "dynamic" devices. The main one probably being pty's, in fact. It's easily conceivable to have thousands of pty's - I suspect that for various other reasons most system administrators would prefer to farm things out so that it isn't _needed_, but clearly we want at _least_ 16 bits here. 20 bits is reasonable.

And remember: for the future, what we want to move towards is _name_ lookup, not device number lookup. Stupid SCSI people have wanted to partition the minor number for a long time, and that's always been idiotic. If you have a sparse name-space, you should use names, not numbers.

So people who want to see /dev/scsi/bus0/dev12/lun4/part0, use devfs or something, don't try to make the number space be sparse. Sparse numbers are a stupid idea for _anything_ but maybe CPU design (I'm willing to concede that a 256-bit address space might be useful on a CPU level, because a CPU really cannot afford to do name lookups when looking up addresses, even if it has been tried).

In short, a 64-bit dev_t is unnecessary. And according to the maxim of "don't go overboard just because you _can_", I don't want to see it.

Also, I have looked at your argument for "simplicity", and I dismiss it. I do not believe that the cases you claim are "simpler" are really simpler. I showed that your pid_t example was completely unrealistic, and as far as I can tell your "dev_t" example absolutely _hinges_ on the fact that it makes anonymous dev_t allocation simpler.

And that falls flat on its face simply because it's _already_ so simple that it doesn't matter.

Linus

This is my opinion on the issue. Short summary: "I'm sick of the administrative burden associated with keeping dev_t dense."

That's how ludicrous a *dense* 64-bit device number is. I have to say I disagree with you that sparse number spaces are a bad idea. The IPv4->IPv6 transition people have looked at the issues of number spaces and how much harder they get to keep dense when the size of the numberspace grows, because your lookup operation becomes so much more painful. Any time you have to take a larger number space and squeeze it into a smaller number space, you get some serious pain.

Part of the reason we haven't -- quite -- run out of 8-bit majors yet is because I have been an absolute *bastard* with registrants lately. It would cut down on my workload if I could assign majors without worrying too much about whether or not that particular driver is really going to be made public.

64 bits is obviously excessive, but I really don't feel comfortable saying that only 12 bits of major is sufficient. 16 I would buy, but I don't think 16 bits of minor is sufficient. Given that, it seems to me -- especially since dev_t isn't exactly the most accessed data type in the universe -- that the conceptual simplicity of keeping the major and minor separate in individual 32-bit words really is just as well. YES, it's overengineering, but the cost is very small; the cost of underengineering is having to go through yet another painful transition. Unfortunately, the Linux community seems to have some serious problems with getting system-wide transitions to happen, especially the ones that involve ABI changes. This needs to be taken into account.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

No.

The real problem, in my opinion, is needing device numbers in the first place, for stuff that really shouldn't use them.

I don't want to make allocation easy. In fact, I want to make it _harder_. I like it being painful, because it should not be done.

I've seen _way_ too many instances of "let's create a special device" for no good reason. For example, all the crap about mice was (and is) a mistake. And that's the least of the problems. Some devices on the device list are there mainly as just a way to hook in an ioctl or something. It's sad, and it's wrong.

And I'm sorry, but I do NOT want to envision a future where you can say "ok, majors in the range 512-576 are PPC-specific, and you can go wild". Yes, it would make your job easier. But it would make for a BAD SYSTEM, which is what _I_ care about.

We should encourage people to not need major numbers. It's easy. The driver exports a /proc entry in /proc/driver/xxx or similar . Or the driver writer says "if you want to use this device, use devfs", and exports the name there.

Don't get the issue of "it would make my life easier" override the issue of "it's the wrong thing to do".

Another example: all the stupid pseudo-SCSI drivers that got their own major numbers, and wanted their very own names in /dev. They are BAD for the user. Install-scripts etc used to be able to just test /dev/hd[a-d] and /dev/sd[0-x] and they'd get all the disks. Deficiencies in the SCSI layer made it impossible for a driver writer to be nice to the user, so instead they got their own major numbers.

But again, you're arguing for _more_ badness. While I'm of the opinion that we _already_ have too many major numbers, and we should realize that, and not make it worse.

A 64-bit dev_t only makes it _easier_ to continue to be stupid about things.

And that, btw, is the hallmark of "bloat". Bloat is not about being big. Bloat is about being slow and stupid and not realizing that it's because of design mistakes.

Linus

Sorry here I have to disagree. This is _policy_ and does not belong in the kernel. I can call them all /dev/hdfoo or /dev/disc/blah regardless of major/minor encoding. If you dont mind kernel based policy then devfs with /dev/disc already sorts this out nicely.

IMHO more procfs crud is also not the answer. procfs is already poorly managed with arbitary and semi-random namespace. Its a beautiful example of why adhoc naming is as broken as random dev_t allocations. Maybe Al Viro's per device file systems solve that.

Not deficiencies in the SCSI layer, there is no way the scsi layer can handle high end raid controllers. In fact one of the reasons we can beat NT with some of these controllers is because NT does exactly what you suggest with scsi miniport driver hacks and it _sucks_. Its an ugly hack.

A 20bit minor space actually solves most of this anyway. All the drivers taking 8 majors suddenely need only one. We go back to 1 major per raid controller class worst case. and we just about have enough minor numbers for the extreme S/390 configuration of 65536 DASD volumes with 16 partitions per volume.

12:20 sounds good to me. If need be we can have extend the small allocations space as we have with 10,* now.

Alan

We could do this fairly _trivially_ today.

With absolutely no performance degradation.

With a simple "queue" mapping for the SCSI majors. Just look up which queue to use for requests to which major, and you're done. The actual IO may by-pass the SCSI layer altogether.

So I'm absolutely not advocating using the SCSI layer for the high-end-disks. Rather the reverse. I'm advocating the SCSI layer not hogging a major number, but letting low-level drivers get at _their_ requests directly.

Linus

Am I hearing you state you want dynamic device points and dynamic majors? Thus would be nice because the ridge structure now prevents a lot if things from developing.

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------

ASL, Inc.                                     Toll free: 1-877-ASL-3535
1757 Houret Court                             Fax: 1-408-941-2071
Milpitas, CA 95035                            Web: www.aslab.com

Yes and no.

We need static structures for user space - from a user perspective it makes a ton more sense to say "I want to see all disks" than it does to know that you have to do /dev/hd*, /dev/sd* plus all the extra magic combinations that can happen (USB etc).

So in a sense what I'm arguing for is for _stricter_ device numbers to the outside world.

But internally, it would be reasonably easy to make a mapping from those user-visible numbers to a much looser version.

One example of this is going to happen very early in 2.5.x: the whole "partitioning" stuff is going to go away from the driver, and into the ll_rw_block layer as just another disk re-mapping thing. We already do those kinds of re-mappings for LVM reasons anyway, and partitioning is not something a disk driver should know about, really.

And that kind of partitioning mapping automatically means that we'd need to remap minor numbers, and do it on a per-major basis (because the partitioning mapping right now is not actually the same between SCSI and
IDE: IDE uses six bits of partitioning, while SCSI uses just four bits). And once you do that, you might as well start "remapping" major numbers too.

So let's say that you have two separate SCSI controllers - they would both show up on major #8, and different minor numbers. Right now, for example, controller 1 might have one disk, with minors 0-15 (for the whole disk and 15 partitions), and controller 2 might have two disks using minors 16-47.

As it stands now, the SCSI layer needs to do the remapping, and because the SCSI layer does the remapping, nothing but SCSI layer devices can use major #8.

But once you start doing partition mapping in ll_rw_block.c, you might as well get rid of the notion that "SCSI is major 8". You could easily have many different drivers, with many different queues, and remap them all to have major 8 (and different minors) so that it looks simple for a user that just wants to see SCSI disks.

Which is not to say that the same disk might not show up somewhere else too, if anybody wants it to. The _driver_ should just know "unit x on queue y", and then the driver might do whatever it wants (it might be, for example, that the driver actually wants to show multiple controllers as one queue, if the driver really wants to for some reason). And it should be possible to have two drivers that really have no idea at ALL about each other to just share the same major numbers.

Linus

Then please please please demangle other cases as well! IDE is the one which is badging my head most. SCSI as well...

Granted I wouldn't mind a rebot with new /dev/* once!

This seems to me to really be the kind of thing devfs does better than trying to play number games. devfs (and I'm talking in the abstract, not necessarily the existing implementation) can present things in multiple views, using hard links. This is a Good Thing, because it lets you ask different questions and get appropriate answers (one question is "what are my disks", another is "what are my SCSI devices".)

As far as IDE is concerned, I repeat my call for "generic ATAPI" to go along with "generic SCSI"...

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

diff -urN linux-2.4.3-p8-pristine/include/linux/major.h linux-2.4.3-p8/include/linux/major.h
--- linux-2.4.3-p8-pristine/include/linux/major.h Sat Dec 30
11:23:14 2000+++ linux-2.4.3-p8/include/linux/major.h Sun Mar 25
22:16:42 2001
@@ -171,4 +171,18 @@

        return SCSI_BLK_MAJOR(m);

}

+/*
+ * Tests for IDE devices
+ */

+#define IDE_DISK_MAJOR(M)      ((M) == IDE0_MAJOR || (M) == IDE1_MAJOR || \
+                               (M) == IDE2_MAJOR || (M) == IDE3_MAJOR || \
+                               (M) == IDE4_MAJOR || (M) == IDE5_MAJOR || \
+                               (M) == IDE6_MAJOR || (M) == IDE7_MAJOR || \
+                               (M) == IDE8_MAJOR || (M) == IDE9_MAJOR)

+
+static __inline__ int ide_blk_major(int m)
+{
+ return IDE_DISK_MAJOR(m);
+}
+
#endif

Well I banged my head and learned a scsi-trick....

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------

ASL, Inc.                                     Toll free: 1-877-ASL-3535
1757 Houret Court                             Fax: 1-408-941-2071
Milpitas, CA 95035                            Web: www.aslab.com

A major for 'disk' generically makes total sense. Classing raid controllers as 'scsi' isnt neccessarily accurate. A major for 'serial ports' would also solve a lot of misery

But it might also cause just as much misery, specifically because things move around too much.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Actually, it probably won't. As has already been said in the past, the names are effectively a user space issue, but major numbers aren't.

I for one would like to see a major number for all 'serial ports' whether they be embedded ARM serial ports _or_ standard 16550 ports, but at the moment its not easily acheivable without introducing more mess.

Ted indicated to me a while ago (just after I wrote serial_core.c for yet-another-type-of-ARM-serial-port) his visions of the direction serial stuff should take in 2.5; this is obviously one of the things that I'm keen to discuss and solve in 2.5.

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

A change to a 12:20 major:minor dev_t would be a great help for the various serial drivers that I write and help maintain. We currently as a company maintain 4 different serial device drivers for linux and all of them currently use between 4 and 10 majors in order to have enough raw minors available to identify the maximum port count supported. We had to do the same think on SunOS (which also has 8:8) in order to support reasonable port counts there. I'd absoultely love the ability to get back on a single major per driver.

I'd like to see all of the serial drivers shipped in the kernel tree be configured by default to use the same major.. but I wouldn't want to have external drivers forced onto that major as well.

Jeff Randall - [email protected]  "A paranoid person is never alone,
                                       he knows he's always the center
                                       of attention..."

Exactly. It's just that for historical reasons, I think the major for "disk" should be either the old IDE or SCSI one, which just can show more devices. That way old installers etc work without having to suddenly start knowing about /dev/disk0.

But hey, maybe I'm wrong.

Linus

They would still have to change, since now we'd have to worry about /dev/hd* having changed meanings; also, you now cannot create a backward-compatible /dev since /dev/hdc is (22,0), etc, in the current scheme. The SCSI scheme is also not acceptable; it has been a long-standing problem that it doesn't allow enough partitions per disk.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

This is why I'd select the SCSI major, which has always had more of a "random disk" connotation, with fewer people being aware of the fact that it's specifically IDE.

Note that neither of these are really problematic, for the simple reason that once you do mapping, the m:n mapping pretty much automatically falls out of this. It's actually hard to think of a mapping that wouldn't allow multiple major numbers to be mapped to the same devices (and in different ways).

For example, it is not hard at all to have a IDE disk show up in three
places: the traditional /dev/hdx place, as /dev/sdx (the SCSI CD-ROM emulation already ends up doing this, I think) _and_ potentially as a "new and improved" non-backwards-compatibility place which would be /dev/diskx and would take advantage of the larger minor number space.

For example, it would probably not be a bad idea to have something explicitly in "high" major number space that would be something like

	/dev/disk<n>p<m>

where <n> would be the disk number, and <m> would be the partition number, and just map it to <major=256>, <minor=(n<<8)+m>. Old installers would still see the device, but couldn't access more than 15/63 partitions (for SCSI/IDE numbering respectively).

And the thing is, this would not complicate the mapping. The only worry would be one of virtual aliases, but kdev_t should pretty much take care of that.

So while we probably eventually want to switch everything over to a new "disk n" numbering scheme, but for backwards compatibility reasons the old numbers won't go away (and knowing how some people work and administer their sites, they'll stay with us for a _loong_ time and will need to be supported even with new drivers that don't actually share any code with "IDE" or "SCSI").

So the IDE/SCSI numbers will have to stay. And they'll have to be considered "supported", not just "old compatibility stuff that new drivers don't have to care about". But done right, none of this will be _visible_ to drivers, so it should not add any ugliness. It shouldn't even be visible to the mapping layer, except as yet another mapping (that just happens to alias with other mappings).

Linus

They will mostly break. Installers tend to parse /proc/scsi and have fairly complex ioctl based relationships based on knowing ide v scsi.

/dev/disc/ is a little un-unix but its clean

Then make a '/proc/block/{ide|scsi|raid|wtf|ram|net}' which has a string name for a real mknod thingy that includes the major|minor of the animal.

Is this simpler than the problem?

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------

ASL, Inc.                                     Toll free: 1-877-ASL-3535
1757 Houret Court                             Fax: 1-408-941-2071
Milpitas, CA 95035                            Web: www.aslab.com

Why do you worry about installers? New distro - new kernel - new installer
that's they job to worry about it. They will change the installer anyway and this kind of change actually is going to simplyfy the code there, I think,
a bit.

Just kill the old device major suddenly and place it in the changelog of the new kernel that the user should mknod and add it to /dev/fstab before rebooting into the new kernel. Hey that's developement anyway :-) If the developer boots back into the old kernel just other mounts
in /dev/fstab will fail no problem for transition here in sight...

Because the same code tends to be shared with post install configuration tools too.

So change them as well for a new distribution. What's there problem. There isn't anything out there you can't do by hand. Fortunately so!

So users cannot go back and forward between new and old kernels. Very good. Try explaining that to serious production -users- of a system and see how it goes down

If anything I'm a *SERIOUS* production user. And I wouldn't allow *ANYBODY* here to run am explicitly tagged as developement kernel here anyway in an production enviornment. That's what releases are for damn.
Or do you think that Linux should still preserve DOS compatibility in to the eternity as other "popular" systems do?

You still break 2.4-2.6. Thats a production release jump. Right now I can and do run 2.0->2.4 on the same box. If you dont understand why to many people that is a requirement please talk to folks who run real business on Linux

You have possible no imagination about how real the business is I do :-).
What's worth it to be able running 2.0 and 2.4 on the same box? I just intendid to tell you that there are actually people in the REAL BUSINESS out there who know about and are willing to sacifier compatibility until perpetuum for contignouus developement.

BTW we don't run much of Cyrix486 hardware anymore here.. More like boxes with few gigs of ram 4 CPU's RAID and so on...
The single biggest memmory hog here is currently the Oracle 9i AS.

And many people who require the ability to drop back one or two versions (major versions) on a problem. Every upgrade requires a getout path

Right. So if we go to 64 bits NOW (in 2.4), then when after 3.2 we actually start needing > 16 bits of dev_t everyone can downgrade to 2.0, except those people who use drivers that require those extra bits.

The further away from "the deadline" that we switch, the easier it becomes to provide a smooth upgrade path. When we have 65536 devices in use, when we finally switch, you can bet your ass we'll be using the "new" device number space right away. However, if we're still comfortable with the 16 bits, we can upgrade the infrastructure ASAP, and make the "no return" switch later. Much later.

Roger.

** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

[email protected] (Martin Dalecki) wrote on 28.03.01 in <[email protected]>:

Make them finally use UUIDs and /proc/partitions. Except for the root fs, problem solved. (Well ok, someone needs to create the right device nodes.)

As for the root fs, even that part isn't hard with an initrd.

MfG Kai

And IDE disk ver CD-ROM f and block vers. raw devices and so so at perpetuum. Those are the reaons why the density of majros ver. minors is exactly
revers in solaris with respect to the proposal of Linus..

And then we have all those VERY SPARSE static arrays of major versus minor devices information (if you look at which cells from those arrays are used on a running system which maybe about 6-8 devices actually attached!)

The main sheer practical problem to changing kdev_t is the HUGE number of in fact entierly differnt drivers sharing the same major
and splitting up the minor number space and then hooking devices with differnt block sizes and such on the same major. Many things in the block device layer handling could
be simplefied significalty if one could assume for
example that all the devices on one single major
have the same block size and so on...

In some ways, they make matters worse -- now you have to effectively keep a device list in /etc/fstab. Not exactly user friendly.

devfs -- in the abstract -- really isn't that bad of an idea; after all, device names really do specify an interface. Something I suggested also, at some point, was to be able to pass strings onto character device drivers (so that if /dev/foo is a char device, /dev/foo/bar would access the same device with the string "bar" passed on to the device driver -- this would help deal with "same device, different options" such as /dev/ttyS0 versus /dev/cua0 -- having flags to open() is really ugly since there tends to be no easy way to pass them down through multiple layers of user-space code.)

The problems with devfs (other than kernel memory bloat, which is pretty much guaranteed to be much worse than the bloat a larger dev_t would entail) is that it needs complex auxilliary mechanisms to make "chmod /dev/foo" work as expected (the change to /dev/foo is to be permanent, without having to edit some silly config file) -- this is where the policy comes in, much more so than namespace -- and the fact that it tries to impose a namespace on character devices which is utterly different from the currently established interface. It may very well be "better" (although /dev/misc/ is much too ugly to live -- if you have to separate things up, do so on functional lines!!!), but it is still *different*, which means it breaks anything that accesses char devices. Block devices, obviously, is not a problem -- that's what /etc/fstab is for.

At OLS, I discussed the following issues with Richard and Alan. We didn't really reach an agreement -- I hope we can discuss it again at the kernel summit -- but I wouldn't object to devfs if it resolved these issues:

a) A way to allocate device nodes without automatically instantiating them in kernel space. For devices where each minor doesn't require kernel memory until used, the devfs overhead easily becomes unacceptable.

b) Use the established namespace, or put forward a comprehensive plan to alter the namespace -- and do the necessary legwork to obtain buy-in from everyone concerned. In the case of tty's, this means modifying the locking protocol; this in itself isn't a bad thing (the locking protocol has some serious flaws), but it needs to be explicit, written down, and widely publicized, well ahead of time. A flag day of this magnitude will *HURT*.

c) Make sure chown/chmod/link/symlink/rename/rm etc does the right thing, without the need for "tar hacks" or anything equivalently gross.

Richard indicated being willing to fix (a) and (c). (b) is the main sticking point at this stage.

That being said, I will be perfectly happy to acknowledge that using a device filesystem has some nice features, especially in conjunction with hotplugging devices. It is definitely far better than /proc hackery, and does permit putting the object-oriented aspects of the VFS to good advantage. The bloat is an issue, but with the memory sizes available today it's less than it has been in the past.

Modulo the issues I have listed above, I would at this stage be in favour to move to a devfs-based system, especially after Al Viro's "one filesystem" (filesystem always exists in exactly one copy, regardless of if it is mounted or not) changes. I know this is probably a bit of a shock to lots of people, but times change; hotplugging is a major issue these days, big memories are available without requiring a matching big budget, and there seems to be a bigger willingness to work out the remaining issues. What I would like to see is working out the issues listed above, and then rather quickly move to a devfs-*BASED* system (devfs is the only way to do devices), so that we can take advantage of the VFS.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

write-through filesystem, like overlaying a r/w ext2 on top of an iso9660 fs.

-Dan

This is not necessarily the right way to do it, since it may not carry with it the appropriate information. Richard, I belive, was planning to implement this using devfsd.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

I did, back in April 2000. I'm fairly sure I told you at OLS :-)

Create and change events can be passed to devfsd and this may be recorded in a filesystem.

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

functionality to do this is in devfs and devfsd already.

there are 2 ways:

1. devfs on /dev, maintain state in /dev-state.
2. regular ext2 (devfs naming style) /dev and devfs mounted on, eg, /devfs for hotplug and module load/unload updates

1:

/dev-state -> regular ext2
/dev -> devfs

use the CREATE, CHANGE and REGISTER hooks that devfs has to allow devfsd to transparently copy changes in /dev to the ext2 /dev-state. See the example devfsd.conf for appropriate entries, eg:

REGISTER       .*              COPY    /dev-state/$devname $devpath
CHANGE         .*              COPY    $devpath /dev-state/$devname
CREATE         .*              COPY    $devpath /dev-state/$devname

2:

/dev -> regular ext2
/devfs -> devfs

use the devfs hooks for REGISTER and UNREGISTER to have devfsd update the static /dev whenever hotplug events occur. Eg:

REGISTER        .*              COPY    ${mntpnt}/$devname /dev/$devname
UNREGISTER      .*              CFUNCTION GLOBAL unlink /dev/$devname

seems to work for me:

[root@fogarty /devfs]# ls -l /dev{,fs}/misc/nvram
ls: /dev/misc/nvram: No such file or directory
ls: /devfs/misc/nvram: No such file or directory
[root@fogarty /devfs]# modprobe nvram
[root@fogarty /devfs]# ls -l /dev{,fs}/misc/nvram

crw-r-----    1 root     root      10, 144 Jan  1  1970 /devfs/misc/nvram
crw-r-----    1 root     root      10, 144 Mar 28 01:56 /dev/misc/nvram

[root@fogarty /devfs]# rmmod nvram
[root@fogarty /devfs]# ls -l /dev{,fs}/misc/nvram
ls: /dev/misc/nvram: No such file or directory
ls: /devfs/misc/nvram: No such file or directory

i prefer option 2 as /dev state is then not dependent on devfsd being there and it just sidesteps the whole permissions issue. if devfsd doesn't start then i still have a fully functional /dev.

but anyway... there seems to be loads of scope to do lots of different things with devfsd, plus NIS support. :)

regards,

Paul Jakma	[email protected]	[email protected]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
-------------------------------------------
Fortune:
Premature optimization is the root of all evil.
		-- D.E. Knuth

Guys, before you get all hot and excited about devfsd - had _anyone_ audit the protocol implementation for races? Or test it for heavy (un)loading drivers, for that matter. We had a long history of autofs races and devfsd is not simpler.

Coll toys are cool toys, but I wouldn't bet a dime on devfsd ability to deal with adding/removing entries 100% correct in all cases. And /dev has slightly larger user base than autofs, so it _is_ a sensitive area.

In its current form devfs itself _still_ contains known races. Known since last Summer. Adding devfsd into the mix doesn't make the picture prettier. Unless some devfs proponent is willing to do such analysis all references to devfsd are nothing but wishful thinking.

the permanent storage for a PC computer is naturally the hard disk. you could always make a device partition to store persistant state. i think a few megabytes should be enough. it could be substatially less if you had good defaults and disk storage was only used to override the default.

of course, using disk brings us full circle back to device nodes on filesystem. the impetus behind devfs was never (afaict) saving disk space or getting around slow disk access. people want device nodes to appear automatically and go away again when drivers are removed.

i think what all this means is that between kernel and collection of the user space programs the filesystem semantics just doesn't have enough going for it in order to do all that you want with devices.

it might be a mostly userspace solvable problem. a device daemon could create new devices on the fly, only they'd be ordinary filesystem devices. for example it might be better to hack ls to not show dormant devices. a cronjob could call a grim device reaper to cull nodes not used for a long time...

what do other vaguely unix-like systems do? does, say, plan9 have a better way of dealing with all this?

--
J o h a n K u l l s t a m
[[email protected]]

Why the hell do we have to reinvent every wheel out there? Especially when we _already_ have that wheel... You don't need to hack ls in order to deal with "dormant" entries. That's what autofs is for. Doing that quite fine, thank you very much. Furrfu...

Plan9 doesn't have devfs. You can say
bind -a #f /dev
and that gives you /dev/fd[0-3]{disk,ctl}. I.e. /dev is a union of device filesystems you've mounted (bound, actually) there. Combined with autofs (and replacing bind #f with mount -t devfloppy) it's pretty much what we could use.

Think of devpts - it's the same kind of beast. As for putting stuff into /etc/fstab - not funny. /etc/auto_dev would do just fine, especially if /etc/fstab would contain the minimal (==permanent) subset. Nothing stops you from examining /lib/modules/ and updating /etc/auto_dev from rc scripts upon boot.

IRIX allows the partition (logical volume identification) to list every volumn name as a device. Then you can mount via the name. Disks can be relocated while the system is shutdown and the mounts still work after boot.

My suggestion would be to add a filesystem label (optional) to the homeblock of all filesystmes, then load that identifier into the /proc/partitions file. This would allow a search to locate the device parameters for any filesystem being mounted. If the label is unavailable, then it must be mounted manually or via the current structure. This would work for floppy/CD/DVD (although SCSI versions would have a relocation problem for these devices).

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]

Any opinions expressed are solely my own.

And what would you do if the names collide ?
This might work for drives with unique identifiers in hardware, but for anything else it is a nice addition, but I wouldn't identify an essential partition that way. Furthermore you need to address removable media. There a way to specify a drive opposed to a filesystem or medium is needed.

Regards
Oliver

Oliver Neukum <[email protected]>:

refuse to mount - give the admin time to fix them in single user mode changing a volumn name only should not be prevented. How to fix... let the admin look in the /proc/partitions, take one (I'd pick the second one seen) and change its name. Mount the first using the devfs associated name and verify that the contents are what is expected. Mount the second and see what it should be. This situation should only occur via a dd copy of an entire volumn; the procedure on copying should include changing the copied volumn name... This is almost equivalent to having multiple mirror partitions, in which case a "mount the first seen" would be reasonable.

I didn't mean to say that there should be NO way to reach a specific drive. There should be a devfs entry that corresponds to the entries in the /proc/partitions list. This is what I think mount should do anyway. First search the /proc/partitions list for the volumn; then use the associated entry in devfs to actually do the mount. It's just a way to allow the reorganization of volume to device name mapping.

I'm still thinking about how the root filesystem could be mounted during boot where devfs and /proc are not yet mounted.

There should be a similar way to map removable media devices (even if it takes using device serial numbers) to fixed device names. That way a symbolic link could be created to point to the correct physical device:

ie: I want my SCSI tape drive (serial number 06408-XXX) to be called "tape"

locate the serial number in /proc/scsi/scsi. use devfs name that corresponds to this device (scsi2/target 6/lun/00 or similar) and create a symbolic link for it. This does assume that the serial number or equivalent is available to be searched for. It also assumes that the devfs name can be derived from the entry in /proc/scsi/scsi (or where ever the specification ends up).

Is this reasonable? Perhaps not for small systems, but when lots of dynamic devices are available it is needed

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]

Any opinions expressed are solely my own.

That means that it could only be used for optional filesystems otherwise booting unattended is put into question.
A user set for a practical joke could prevent booting by leaving a medium in the drive. You could add options for not considering removable media, etc, but you get to a stage where you design workarounds. That'd be bad for core filesystems. Thus the need for a second improved system remains.

Aside from that adding the name to /proc/partions is a good idea but not universally usable.

Enable the kernel command line to understand devfs names.

This is the problem. I wouldn't trust it.

It is reasonable. GUIs could use a unified way to learn volume names.

Regards
Oliver

Yes.

Normal UNIX has as well. For reffernece see: block ver raw devices on docs.sun.com :-).

Devfs is from a desing point of view the duplication for the bad /proc design for devices. If you need a good design for general device handling with names - network interfaces are the thing too look at. mount() should be more like a select()... accept()!

And what on earth makes this better? I have always thought the socket interface to be hideously ugly and full of ad-hockery. Its abstractions for handle multiple address families by and large don't work, and it introduces new system calls left, right and center -- sometimes for good reasons, but please do tell me why I can't open() an AF_UNIX socket, but have to use a special system call called connect() instead.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Aye. The real problem with mount is that it always had been pretty heavy-weight. Especially mount(8). I've done some (very rough) testing on my tree - for ramfs-style filesystem latency of mount(2) is about 20% worse than latency of open(2). And it definitely can be improved - right now I'm interested in getting the code cleaned.

mount(8) is a problem, but in nosuid namespace we can seriously cut down on checks in the thing. And I'm very interested in designs that would allow killing /etc/mtab - dropping it would allow very easy mounting.

The elegant solution seems obvious to me. What we have today is two namespaces--device major/minor, and filesystem--that are bridged by special files. Special files live in the filesystem namespace and point into the major/minor namespace. Objects in the major/minor namespace are directly accessible only by root (ie, only root can mknod(2)); but when accessed through special files, access control comes from the special file.

The concept that makes this work is that the special file is a "pointer with permissions". To make devfs work, you want the same thing--except a pointer into filesystem space, not major/minor space. Unix doesn't have this, but it would be a simple cross of symlinks (pointer living in the filesystem and pointing into the filesystem) and special files (pointers with permissions).

To be concrete: You'd have a root-only (or perhaps the directories could be a+rx--but minimal policy) hierarchy under /devices, and the admin would populate /dev with "special symlinks" that point into /devices, and give the appropriate permissions to users.

I have no idea whether this is feasible, but it is much more attractive to me than devfsd, or layered mounts, or tar at shutdown, or anything else I've heard.

Andrew

This can be done with an lchmod() and support for setuid symlinks.

Read     can see where the link points
Write    ignored, or XOR the on-disk data with 0222 and...?
Execute  can follow the link
Setuid   link followed as for the owner
Setgid   link followed as for the owner's group
Sticky   reserved for future use

Then you get:

lr-sr-xr-x 1 root root 17 Mar 21 2000 /dev/null -> /devices/mem/null

Then just tell me please why the PCI name space is just 32 bit?

Majros are for drivers Minors are for device driver instances (yes linux does split minors in a stiupid way by forexample using the same major for IDE disks and ide CD-ROM, which are in fact compleatly different devices just sharing driver code... (Dirrerent block sizes, different interface protokoll and so on....)

Those are the reaons solaris is using a split 24/12 (Major/Minor) and they don't have our problems here.

- phone: +49 214 8656 283
- job:   eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort:
ru_RU.KOI8-R

Well, one solution to this on the long term comes quite naturally:
make major/minor separation a policy, i.e., as in network/host IP numbers. That is, in addition to 32-bit dev_t there would be a 32-bit devmask_t that when &-ed with dev_t would yield the major. The default, for compatibility reasons will be devmask of 255 (or -1+1<<12). For example, all floppies would fall into 2/8 major (using IP address notation). Obviously, all this is not advantageous on the short term, but in the absence of better ideas, this can give some flexibility when allocating/shifting to new majors/minors...Of course, namespaces approach is even better, but when will all drivers be converted to support them?

Cheers,

Pjotr

Are the major/minor numbers neccessary at all? They were a kludge to represent devices in the file system because there wasnt something like DevFS in the dark ages of Unix. But if you take DevFS as given you can get rid of all these problems that major/minor numbers cause, just register your file_operation structure directly instead of your maj/min pair (plus, maybe, some private data that replaces any information that was encoded in the minor number).

While DevFS may not be very popular this could actually reduce the amount of code in the kernel, which was one of the main arguments against DevFS AFAIK. And if you dont like the fact that DevFS assignes the file names you could mount DevFS in a different directory and use symlinks from /dev to the device tree (like Solaris does?).

bye...

...

...

In your dreams!!!!

int c_has_loose_type_checking(char *name){
struct stat sbuf;
/* ... */
return sbuf.st_rdev;
}

Then we have NFSv2, archive file formats, and zillions of little tools.

I enjoy truncating dev_t to a reasonable size. Sometimes I check my input arguments for illogically huge values, and other times I just relish the opportunity to inflict data loss on you personally.