Kernel Traffic #57 For 6 Mar 2000

I don't know how he did it, but Jon Lasser found a bug in this issue almost before I put it up! (the date of the issue said March 7th instead 6th) Many thanks, Jon! :-)

There were 482 different contributors. 222 posted more than once. 199 posted last week too.

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."

I want to propose the following two changes in the implementation of the syncppp layer in linux/drivers/net/wan/syncppp.[ch]. The syncppp handling is currently different than the ethernet one (and fddi and TR too), which causes some code duplications in the drivers and a suboptimal implementation in syncppp.c. Let me know what do you think about the following (i have it partly done in my tree):

Proposals:

implement the equivalent of eth_type_trans(skb, dev) for the syncppp devices.
implement the common device allocation & registration code similar to the init_etherdev() and ether_setup() routines.

Rationales:

currently the protocol type in the received packet is set to ETH_P_WAN_PPP, the packet is passed to netif_rx(), and the sppp_input() routine then changes the skb->type to the appropriate 3rd-layer protocol (IP or IPX) and passes the skb to netif_rx() once again. This is wrong and it caused misinterpretation in tcpdump and ipchains in the past (the packet is seen twice by the network stack). LCP or Cisco keepalive packets are handled directly (and thus are seen only once).

I think it will be better to have the sppp_type_trans(skb, dev) routine for setting up the skb->proto, skb->mac.raw, and maybe skb->dev fields. It should immediately decide between the ETH_P_IP, ETH_P_IPX and assign the ETH_P_WAN_PPP type to the LCP and/or Cisco packets (XXX or there can be a separate type ETH_P_CISCO for Cisco HDLC). The skb with the correct type then will be passed to netif_rx(), and it will end up in the IP, IPX or SyncPPP/Cisco routines, respectively.
currently all users of syncppp.c (I know of cosa.c, hostess_sv11.c and sealevel.c, maybe there are others too -- comX?) use their own homegrown method of allocating the struct net_device, the dev->priv, the struct ppp_device and the dev->name. On the other side there is a clean method used by all ethernet drivers -- the init_etherdev() and ether_setup() routines.

I propose to implement the init_spppdev(dev, sizeof_priv) routine, which will allocate the struct net_device (if needed) and all the other structures, sets up the syncppp device part (struct ppp_device) and initialize the syncppp layer using sppp_attach() (which seems to be a good equivalent of ether_setup()).

When we have the common allocation/setup/registration method of struct net_device for syncppp devices, we can also get rid of the if_ptr ugliness, and map the struct ppp_device at the beginning of the dev->priv instead (thus every device using syncppp.c should have the struct ppp_device at the beginning of its dev->priv the same way it currently has to have the pointer to this structure there). This saves a one pointer in dev->priv.

Possible implementation problems:

Should the ETH_P_WAN_PPP be reserved for LCP/IPCP frames only (and add something like ETH_P_CISCO for Cisco HDLC keepalive and other frames)? Or should I use ETH_P_WAN_PPP type for both Cisco HDLC service frames and PPP (LCP/IPCP/keepalive) ones?

Alternatively, the sppp_input can be called instead of netif_rx() by the network driver, but I think it causess too much work to be done at the (possible) interrupt time.
It would be good if the init_spppdev() can use the functions from the linux/drivers/net/net_init.c. But most of these functions are static. We can add the init_spppdev() into net_init.c, but this routine should call sppp_attach, which will need the syncppp.c to be linked into the kernel (possibly with new CONFIG_SYNCPPP option, which would be set if CONFIG_COSA or CONFIG_HOSTESS or CONFIG_SEALEVEL is set).

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."

You are right, I am the one who changed the rtc device.

RTC is the official alpha timer clock. It's a very special irq on alpha delivered throught a special pin and a special case in the irq code. We have to use it as irq clock on alpha SMP. In 2.2.x we are now forced to use an unofficial rtc-light patch to make alpha-SMP to work correctly.

The reason the rtc device still make lots of sense on alpha even if doesn't own the rtc interrupt is that it allows hwclock to play with the RTC time settings.

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:

Not long ago one could build a running kernel for Alpha w/o RTC support. For me, RTC is not important at all *except* to configure the hwclock by hwclock 'cause it faily badly w/o RTC module loaded;(

Well, the actual changes for the Alpha platform show me the some new way: compile RTC _in_ or don't compile it at all. Is that right? Of course I can do so, but since "older" kernel were fine with RTC being only a module I really wonder about that (a bit...) (because I like modules very much;).

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:

Just compile kernel with devfs, add append="root=/dev/ide/host0/bus0/target0/lun0/partXX" (or where are your root is placed) and try to fire up system. System will complain loudly on your "broken" /etc/fstab and you'll be able to enter root password (in most distributions -- this is userland issue) and fix it. Then you'll need to fix /etc/inittab and pile of distribution specific files... Installation of devfs is VERY distribution-specific thing (especially now when there are no compatibility entries by default)... All needed technical background is in mentioned directory...

If you can not imagine how your root will be called after reboot just fire new kernel and look on screen: you'll see needed stuff there. Just "part1", "part2", "part3" and so on will be called "p1", "p2", "p3" and so on.

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:

Oh god not this again.

We went through this cycle during 1.3 and during 2.1 and in both times ended up back where we were.

Ok so how does a non setuid application receive the ICMP errors it needs to make intelligent decisions about load balancing UDP queries in 2.3.x ? If you can't answer that problem cleanly then your change is broken.

Not reporting the error is even more stupid than reporting it. Its always been configurable before. Still it may explain why 2.3.x now hangs during boot starting userspace apps here.

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:

Let's wait a bit with this problem. I had very good reasons to make this and want to observe for reaction a bit more before starting some ado. I know that Alan advocated this Linux specific feature for years, I advocated it too and even more aggressively. But at time when Linux (and me) entered to mature state and started to serve thousands of processes and connections, I started to suspect something wrong. When IP_RECVERR was done, it were purely theoretical doubts.

Now I have no doubts that it is wrong.

The last drop was the accident with CommuniGatePRO. It has high preformance DNS resolver, using not-connected sockets concurrently and at some level of load it fails to resolve names even for local 100% reliable DNS services. I ridiculed its vendor for long time, but had to explain, why only Linux fails yet. The source appered clear, sockets get ICMPs from slow remote servers, which match new innocent sockets. It was the _end_, I shot the feature the same day when found that it is real.

We have to shot it as soon as possible simply because it does not match modern situation. The problem was not seen when nobody really used Linux as loaded server. Actually, exactly with nis it should occur very frequently.

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

I have nothing to add really. We have done this mistake, we have to recognize it and prodigal son Linux returns to his BSD father eventually. 8) It is not tragedy, but rather happy end.

The feature was not used by any applications to now in positive sense, mostly in negative one. That fact that portmap is called even if nobody asked to use RPC is not-related fact and fixing this configuration bug will make Linux apps only faster. It is occasional but lucky finding.

To add, libraries need not any changes. New distribution will have correct nsswitch.conf without spurious "nisplus" switch exactly like Solaris do. That's all. ?ertainly, hooking IP_RECVERR will add robustness, but it rather option than demand.

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"

It's not spurious though... Solaris and Linux' nsswitch has worked in fail-over-to-next-method mode for as long as I can remember. In fact, there is even a RETURN=fail token on Solaris to indicate that failure should abort instead of (the default) trying next mode.

And wearing my MandrakeSoft vendor hat, changes like this in general suck for us, because there are suddenly additional upgrade issues for legacy installs, and addition config versioning issues.

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:

Look folks. All of these arguments are going on deaf ears, because the old behavior is not coming back without a solution to the problem which was solved. The problem we have fixed is several orders of magnitude _worse_ than hostname or username lookups stalling for 30 seconds on a misconfigured system.

As for all the "distribution X is broken now" arguments. Have any of you tried to use RARP with 2.3.x using the tools shipped by any vendor in any release? It won't work, because we tossed rarp from the kernel because it belongs in user space. Yet I hear nobody crying about that.

I feel rather sure that when vendors ship 2.4.x supported kernels for their distributions, they will also provide corrections for these issues as well.

2.4.x is about moving on and fixing the problems of our past, not being stuck with them forever.

Someone mentioned that Solaris deals with dead NIS servers etc. It would be interesting for someone to find out (with strace or something similar) how they detect the NIS server being down, I would not be surprised if they used a timeout mechanism of some sort.

Trace any BSD box and you will find a connected UDP socket delivers ICMP errors to the app. Its been true for over 15 years. Its used by a lot of BSD apps and neither preaching nor sitting on #linux with your fingers in your ears going "NotListeningNotListening" loudly will change that. They use timeouts too but then fast error recovery occurs because icmps for host unreach (dead in arp cache) occur fast.

The only difference between the old Linux and BSD behaviour is that BSD does not return ICMP errors to an unconnected socket. We have supported that since 1.0 (config option) and 1.1 or so (socket option). Note we even support it in a sane back compatible fashion.

That is not to save IP_RECVERR and friends are not good ideas. But they need to be good ideas that default to 15 years of defacto standards behaviour.

You don't get to arbitarily re-invent unix apis, tough but true. Otherwise we could dispose of several useless calls like chdir that can be done in library space.

Ultimately you are punishing millions of working setups by forcing them to turn on a feature instead of providing an off switch to those who want to turn it off.

That isn't good release engineering, it isn't good support engineering, it isn't good design. Now how about putting the defaults back so that Linux 2.3 is binary compatible with Linux 2.2 and API compatible with the real world. Otherwise I can tell you for free what the most popular diff in 2.4.0ac1 will be.

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:

It was not a difference, but plain bug.

Alan, I did not enter to this discussion until direct query and answered to reports pointopoint exactly because I know that it is difficult to reroute brains after years of fighting against all the world. Especially, publically. I passed through this myself, calmed down, brought apologies to people, who blamed on strange Linux behaviour, recognised that they were right and I was wrong.

This thing is not a thing, where discussions can help. It is too simple and evident.

Again:

NIS is not broken, NIS works exaclty as it was designed by its designers.
The fact that it does not return now immediately "no such user", getting ECONNREFUSED is not a flaw but right thing.
Any application which used unconnected UDP socket and failed on ECONNREFUSED and EACCES was buggy. Luckily, most of them are already fixed to _ignore_ these errors.

See?

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:

They have an option for it SOL_SOCKET, SO_BSDCOMPAT. It has been there for years. The right way to fix this would be to set that flag when FAVOUR_BSD is defined in glibc (ie _bsd_socket) . Then nothing else breaks.

The current change is basically vandalism

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:

It is rumoured that Windows 2000 does not accept partition tables that are not ordered according to disk order. (DOS / Win95 / Win98 have no problems, and neither has Linux) If this is true then fdisk must become somewhat stricter. The present version has an expert command f that does a sort. (But, let me repeat, nobody tried this. However, it compiles.)

If anyone happens to have a Windows 2000 system nearby, I would be interested in hearing about what it thinks about unsorted (or otherwise less usual) partition tables, both during an install and during normal operation.

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():



    if((++last_pid) & 0xffff8000) {

        
        last_pid = 300;         /* Skip daemons etc. */

        goto inside;

        
    }

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:

What do you mean unmaintained?! It is very well (well, as time and other duties permits) maintained and the official ABI site is:

http://www.ocston.org/~tigran/patches

The old official site was ftp.infradead.org/pub/abi but it just has a README pointing to my site. We (at least myself) look only after the latest version of ABI, i.e. the latest patch I made was against 2.3.44 I think... Only a week ago I fixed a few bugs in it, so I do occassionally check that it still works and yesterday I received a user bugreport from someone trying to run MicroFocus COBOL under ABI - I am still debugging that one.

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:

There are no docs
There is no driver
There is nobody at Yamaha who cares

AFAICT, per http://www.yamahayst.com/pcaudio/downloads_body.htm, the DS-1x series (YMF724, YMF740, YMF744, YMF754) use the same driver.

Looks like the datasheet at http://www.yamahayst.com/pcaudio/download/index.htm for the YMF-754 should provide enough info to make the SBPro playback-only emulation go. Support for the other nifty features (digital in/out, etc.) shall come when Yamaha acquires a clue. Heck-- even their motorcycle line needs rethinking.

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."

When I wrote this code many years ago (I mean: dynamic allocation of consoles and resizing) my first version allowed for VCs all of a different size. However, that didnt work well for me, so I threw out all complications and only put the current code in the kernel. (Well, I don't know whether it still is the current code, haven't looked at it for five years.)

What was wrong about different sizes? One thing was that the kernel does not have detailed information about all video cards and video modes, so cannot easily change video modes, so an external program was needed. The present system, where Alt-RightArrow cycles through all consoles is easy and convenient, and needs no userspace support.

Another thing was that my monitor/videocard at that time required several seconds to stabilize after a mode change. So even with userspace support working with more than a single text mode was unpleasant.

But if you have hardware that handles mode changes well, and you have the user space support then it is quite possible to do what you want. Probably I would not change the kernel, but make a program listen to KeyboardSignal generated by Alt-UpArrow and let this program do a chvt LogVT followed by a mode change, and make the next KeyboardSignal change back to the original VT. In that way looking at the log and going back is pressing Alt-UpArrow twice, even better than Alt-Fn followed by Alt-Fm. It would be a 20-line program.

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 :)"


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	15 Feb 2000 - 27 Feb 2000	(149 posts)	How To Handle Removable Media
2.	16 Feb 2000 - 24 Feb 2000	(22 posts)	SCSI Device Names
3.	18 Feb 2000 - 22 Feb 2000	(18 posts)	Proposed SyncPPP Layer Modifications
4.	19 Feb 2000 - 22 Feb 2000	(27 posts)	The Real-Time Clock And Portability
5.	19 Feb 2000 - 22 Feb 2000	(27 posts)	devfs
6.	20 Feb 2000 - 23 Feb 2000	(38 posts)	Developers Dispute NIS Implementation
7.	20 Feb 2000 - 22 Feb 2000	(10 posts)	Developers Dispute Direction Of Alpha Patches
8.	22 Feb 2000 - 24 Feb 2000	(4 posts)	fdisk Partition Ordering For Windows 2000
9.	22 Feb 2000 - 23 Feb 2000	(20 posts)	Magic Number In PID Wrapping Algorithm
10.	23 Feb 2000 - 24 Feb 2000	(4 posts)	LVM Makes It Into Official Sources
11.	23 Feb 2000 - 24 Feb 2000	(7 posts)	Status Of IBCS
12.	24 Feb 2000 - 25 Feb 2000	(9 posts)	Yamaha Stingy With Docs
13.	24 Feb 2000 - 28 Feb 2000	(32 posts)	Future Of Console Code

Kernel Traffic #57 For 6 Mar 2000

By Zack Brown