This was a very long discussion of how to handle removable media, such as floppies. Some folks felt that the system should automatically detect, and correctly handle, cases where a disk is removed from the drive, or one disk is replaced by another. Other folks felt that the 'mount' and 'umount' commands were just fine for such things. The debate went on and on, and covered some interesting points. For instance, implementation of such a feature would be extremely difficult, since it would have to deal with things like files that were still open when one disk was replaced with another. On the other hand, the feature is fairly standard in other OSes, and so the argument can be made that users, especially beginners, have a right to expect it. It's the sort of debate that marks the meeting of two worlds. Eventually, I imagine some sort of implementation will be written to be able to switch floppies around and have it just work, but not before many flames have cleared the ground.

Ashok Raj noticed that the kernel would name SCSI devices 'sda', 'sdb', and so on. If the drive switched slots or moved across to a different controller, he pointed out, it could have bad effects. He explained, Worst case is removing a drive and the drive device files dont have a persistant assiciation with the location. He asked if there was a solution for this. Andreas Dilger replied, If you are using ext2 filesystems, you can use the ext2 filesystem "label" instead of the device in /etc/fstab, so you don't get burned by drive name or address changes. See mount(8) and fstab(5) for more info (a newer version of mount is required to support labels). Chris Meadors and Giuliano Pochini were both happy to hear this, but Giuliano asserted, I think it's better to store the name in the partition table instead of in the filesystem. Horst von Brand explained, The (PC) partition format can't be changed now. And there is no space there for a name.

Jan Kasprzak posted the following proposal:

Alan Cox gave his OK to proposals 1 and 2, and to the proposal in the second paragraph of rationale 2; and gave other implementation comments.

Elsewhere, Gergely Madarasz objected to Jan's proposal 2. In a reply to Jan's first post, Gergely explained, The problem I see with this: only syncppp and hdlc protocols can be used on those devices this way. The comx drivers support lapb thru the lapb stack, and they have a minimal frame relay support too. This would mean that different protocols need different initialization stuff, etc... which would make quite a mess, unless all the possible sync serial protocols are integrated into the syncppp driver... So I don't think this is a good idea. Jan replied, Folks, I have proposed the init_spppdev() as a _helper_ function, nothing more. For the ethernet device, you don't have to use init_etherdev() if you want to allocate, name, and register the device yourself. The ether_setup() (and sppp_attach()) is here to help you in this case. Someone replied that this would be fine, as long as the helper function didn't break previous interfaces and procedures (i.e. as long as current code still worked). Alan replied, Realistically it does mean breaking them a bit, and added, If we break anything it is to make it follow the same API as the others. This IMHO is a good thing for all

Ralf Baechle was porting Linux to a platform that used the M58T35 real-time clock, which did not supply the usual /dev/rtc periodic interrupt. He asked which applications (if any) depended on that interrupt, and explained, the question is if it's worth to care at all and possibly emulate an timer interrupt from another source.

Jeff Garzik felt that the RTC driver was pointless without interrupts. Without interrupts, the only thing the driver did was query the RTC status. He assumed that on the M58T35, this status would have a different format as well. He asked, Andrea, since I think (???) this was your patch, why do you disable RTC interrupt on Alpha platform? You might as well disable the entire driver at that point IMHO... Ralph replied, /dev/rtc still makes sense as the interface for setting the clock. The old way of directly accessing the hardware as done in clock(8) is a completly unportable mess, and Richard Henderson agreed, adding, Exactly why we'd like to still keep it for alpha.

Andrea Arcangeli also replied to Jeff's question, explaining:

A bit of discussion followed Andrea's post. Jan-Benedict Glaw was not able to load RTC as a module on his one-processor Alpha system. Jeff asked if this was still true in 2.3.47-pre6, and Jan-Benedict replied that in that version, the module couldn't even be built without heavy patching. He hoped this was not intentional, and that RTC would be usable as a module on his machine in the near future. But Richard replied, Not for interrrupts. My only suggestion, if you want interrupts, is to modify the rtc driver to try and get the PIT to do the job instead. Of course, that will fail on RUFFIAN, which doesn't have its RTC connected to anything, and has to rely on the PIT for timer interrupts. But it's the oddball. Jan-Benedict replied:

Andries Brouwer also replied to Jeff's first assertion that the RTC was pointless without interrupts; Like Ralf, he pointed out the RTC was useful for reading and setting the hardware clock, which was useful for programs like 'hwclock', so that, as user programs, they would not have to tinker directly with the hardware. Ralf replied that he wanted to see the direct hardware tinkering taken out of 'hwclock', since the code to do it was messy and hard to port. Andrea added, going raw on the chip from userspace without kernel iteraction can't be done without races on SMP. There should be at least a BIG warning in hwclock docs and it shouldn't be take as per default thing if rtc device is not available. But he also acknowledged, OTOH I know the door for the SMP race is quite small..

Ian Ehrenwald asked if any 'devfs' documentation was hiding somewhere on the net, aside from the README in 'linux/Documentation/filesystems/devfs', whcih didn't give any examples to follow. Victor Khimenko gave some brief instructions:

There followed a bit of discussion about why the names had changed. Some folks preferred the old names, and some preferred the new. But it was pointed out that by running 'devfsd', it was possible to get the old names back.

Eugene Crosser noticed that somewhere between 2.3.40 and 2.3.45, glibc resolver, among other things, is trying to query the portmapper at localhost. On 2.3.40, it immediately gets ECONNREFUSED but on 2.3.45 it succeeds and waits for answer for 5 seconds, and then makes several more attempts, causing delays. Vince Weaver confirmed the behavior, and David S. Miller explained, Disable NIS entirely on your system. The C library is trying to lookup hostnames and user names using NIS, and since you aparently have no NIS or portmapper running, it times out trying to contact that server. He added that with glibc this could be controlled by editing /etc/nsswitch.conf. Richard Gooch added that editing the same file would work in libc5 systems as well. Vince reported to David that this definitely fixed the problem, but asked why the 2.3.4x kernels made the situation an issue, while earlier kernels did not.

David replied, Our UDP response behavior previously was extremely bad for these sorts of transactions under any load. It was nice for all the simple cases, but as the connection attempt rates increase the possibility of later applications seeing responses meant for previous ones grows larger. The new behavior fixes this hole. But Alan Cox cried out:

David replied, Accidently reporting the error to the next application which happens to unluckily get that same port is even more dangerous. He also quoted an email from Alexey Kuznetsov, and added, Alan, you cannot propose going back to the old behavior without proposing a solution to this problem. The quote from Alexey was:

Alan started to propose some implementation, David disagreed, and called for Alexey to comment. Alexey replied:

Alan, Jeff Garzik and David Parsons all had objections to Alexey's post, but their objections went unanswered. To Alexey's second paragraph, Alan objected, It breaks every single existing machine set up to use NIS by default and relying on the error returns to handle NIS not being present. It breaks failing over from NIS, and to Alexey's third paragraph, where he says that new distributions will have corrected /etc/nsswitch.conf files, without spurious "nisplus" switch, Alan replied, This doesnt solve failure handling when the NIS server vanishes. Right now that works. With your kernel it doesnt

Jeff put this last point in his own words:

And David replied to Alexey's same point, This is not so. I'm sure that /etc/nsswitch.conf is all fine and spiffy, but putting that into libc 4 is not even close to the top of my list of things to do with Mastodon.

Chris Wedgwood also replied to the post in which David quoted Alexey, and David came back with:

But Alan replied:

To Alan's first two sentences, Alexey replied, Exactly. BSD does this because it is well defined behaviour and Linux did and does this exactly by the same reason. And to Alan's "the only difference" statement, Alexey replied:

Alan still disagreed. To Alexey's point number 1, he replied that until the NIS code used connected sockets, it did not, as Alexey asserted, work exactly as it was designed by its designers. To Alexey's second point, Alan merely replied, nope, and to Alexey's final point, Alan concluded:

There was no reply.

Richard Henderson posted an Alpha patch to use Andrea Arcangeli's IRQ infrastructure. It also Cleans up style issues to my liking. He added that the patch had been tested on sx164, up1000, and eb164; and concluded, the eb164 is very similar to your pc164, the only real differences being in the IDE controler. It's using an aic7xxx and two tulips. If this patch doesn't work for you, I'm not sure what to try -- of course, I'd been running other recent 2.3 kernels just fine too....

Andrea took issue with Richard's style "cleanup". He objected, I don't understand why you feel more happy in having include/asm-alpha/hw_irq.h in the wrong place arch/alpha/kernel/irq_impl.h instead of its right location where I moved it in my last patches to make the irq code architectural clean? And you have still to keep hw_irq.h empty to satisfy include/linux/irq.h ;). I think you are missing the larger picture that is you'll have to put hw_irq.h in the right location for sure in the long term (irq.c in linux/kernel/) and so your current move to the past where such code was just ready for the long term move make no sense at all. He added, Please revert the buggy move and resend the patch to Linus. thanks.

Richard replied, No. Please respect my wishes on this and do not send Linus a patch to move it back. He went on, MY point is that <asm/hw_irq.h> is _NOT_ architecturally clean. It provides _NOTHING_ needed by generic parts of the kernel. And in my not so humble opinion, if it isn't needed by anything outside the backend, I shouldn't have to expose it to anything outside of the backend.

To Andrea's comment about him missing the larger picture, and that the files should go in the locations they would need to be in for the long term, Richard disagreed, If and when that happens, we can rearrange things. When I see what's needed for such a generic irq.c, I'll put what's needed in that file. But even if that happens irq_impl.h will STILL exist, because e.g. init_pyxis_irqs has no business in asm/hw_irq.h.

After a bit more discussion, Andrea had the last word, with, It seems you are missing is that I am making the infrastucture to allow alpha to share the same irq.c of i386. I assumed it was clear to everybody. FYI: I am not the only one who thinks this is not a bad thing since there are explicit comments in the kernel that says it will happen in 2.5.0.

It looked as though Richard was gradually being convinced; but there was no real conclusion on the list, even though Linus Torvalds was cc:ed through it all.

Andries Brouwer reported announced util-linux-2.10g, adding that 'fdisk' had some large, untested changes. He went on in a new vein:

Daniel Egger reported that Windows 2000 refused to boot after his 'fdisk' experiments, though he couldn't confirm that the cause was actually 'fdisk'. Jeff V. Merkey replied, I have tried RC3 and the final MSDN release of W2K with out of order entries, and they seem to be OK with out of order FAT, NetWare, and Extended partitions. I have seen some problems with HPFS partitions that have logical drives assigned in them with the new Veritas on-disk formats for W2K, but these seem to be bugs, not any incompatibility issues, and were restricted to RC2 (there was also everal places they were taking KeSpinLock then touching page pool -- nasty). There were some problems with this on RC2 with the partition API, but our latest seems to not have problems with this. Daniel replied that his problem occurred on RC2. End Of Thread.

Richard B. Johnson noticed that On Linux 2.3.41 (haven't checked others) when the PID wraps past 32,767 the next PID is 300. It is not the next-available low one. Does anybody know why? Andries Brouwer replied, This behaviour was introduced in 2.1.37. There is no very good reason. But it separates processes that were started early (init, syslogd, atd, inetd, lpd, cron, etc.) from the usual processes. That may be useful to the sysadm - a process inetd with pid 150 was started at boot time; a process inetd with pid 12053 was not. Having this kind of information may help a bit in maintaining security. But H. Peter Anvin pointed out that, as it was possible to derive the starting time of processes, that would be much more useful for security than relying on some arbitrary PID behavior. Elsewhere, Thomas Strohm posted the relevant code from linux-2.3.41/kernel/fork.c:get_pid():

Again elsewhere, Mike A. Harris explained, the idea behind the 300 wrap is not "this is reserved daemon area", but more like "chances are that most daemons on the system that started up at boot time, are now residing with PID's below 300, so if the routine that looks for a new PID (getpid?) skips these 300, then it will have a better chance at getting a free PID earlier rather than walking through a bunch of PID's that are likely being used allready. This made sense to H. Peter, who reiterated in a different sub-thread, Okay, someone just pointed out that the reason for this is a performance heuristic: the first few hundred PIDs tend to be clogged with longrunning processes, so the PID space is very dense in that range. Thus, skipping over this range is faster than trying to fill it, and it's not worth worrying about potentially losing 1% of the PID space..

Heinz Mauelshagen announced with much glee and excitement, that LVM 0.8final had made it into 2.3.47, and would thus be in the 2.4 stable series; and a cheer went up from the crowd.

In the course of discussion, Manfred Spraul noted that IBCS appeared to be unmaintained. Tigran Aivazian replied indignantly:

Mike Galbraith asked if there was a (preferrably GPLed) Linux driver for the YMF-740C chip, or at least some public docs. Alan Cox replied:

Aaron Burt replied:

Alan replied, regarding whether the datasheet provided enough information, It does not. Trust me I checked. And Dan Hollis added, Several people have tried enabling sbpro emulation according to the docs and failed. There is some other undocumented initialization required. We've been over this several hundred times now, it should go in a FAQ somewhere.

Mike A. Harris looked over the MAINTAINERS file, and noticed there was currently no official maintainer of "console". He had been trying to find out if 2.2.x supported virtual consoles with a different text-mode on each. He explained, I'd like to be able to individually set each virtual console to a different text mode and be able to switch from console to console and have the kernel switch video modes as I go.

To explain the console system, James Simmons explained, Linus orginally wrote it. It has been modified but it really hasn't changed much. When 2.5.X comes out this will change. Several people will be working on the new console system.

A bit later, Andries Brouwer put in:

There followed an implementation discussion. Elsewhere and throughout the thread, several people pointed out that the framebuffer device could handle separate video modes for each virtual terminal. At some point James gave a pointer to The Linux Input Drivers page, adding, This is mostly the input side of it developed by Vojtech. I have been working on the fbdev side. His patch has some multiheaded support to it. After 2.4.X is out we will join forces to find a complete solution :)