RE: Microsoft and Xenix.
> I hope the following adds a more direct perspective on this, as I > was a user at the time. I was _almost_ at university :-). However I do have a first edition of the IBM Xenix Software Development Guide from december 1984. It has '84 IBM copyright and '83 MS copyright. The SCO stuff I have goes back to '83 - MS copyrights on it go back to '81 but that's probably just the compiler and DOS compatibility. Basically Xenix was the first MS/IBM attempt at a "real OS" for the PC. MS realised that multiuser/multitasking was less important than colour graphics for PC owners and decided to pull out of the Xenix business. IBM licensed it under their name to keep their desktop computer concept alive while the Xenix team emerged from the shake out to form SCO. Mike -- Chief Network Architect Mobile: +44 7780 608 368 Kokua Communications LtdOffice: +44 20 7292 1680 52-53 Conduit StreetFax:+44 20 7292 1681 London W1S 2YX - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Microsoft and Xenix.
I hope the following adds a more direct perspective on this, as I was a user at the time. I was _almost_ at university :-). However I do have a first edition of the IBM Xenix Software Development Guide from december 1984. It has '84 IBM copyright and '83 MS copyright. The SCO stuff I have goes back to '83 - MS copyrights on it go back to '81 but that's probably just the compiler and DOS compatibility. Basically Xenix was the first MS/IBM attempt at a real OS for the PC. MS realised that multiuser/multitasking was less important than colour graphics for PC owners and decided to pull out of the Xenix business. IBM licensed it under their name to keep their desktop computer concept alive while the Xenix team emerged from the shake out to form SCO. Mike -- Chief Network Architect Mobile: +44 7780 608 368 Kokua Communications LtdOffice: +44 20 7292 1680 52-53 Conduit StreetFax:+44 20 7292 1681 London W1S 2YX - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux's implementation of poll() not scalable?
Here's something I did last year and then put on ice, partly through lack of time and partly because I thought I'd pick it up for 2.5. All this talk of event queues misses one thing: we already have an event queue mechanism. They're called wait queues. The only problem is that the only on-event action possible is to wake the process (assuming it was asleep in the first place). This patch firstly extends the wait queue mechanism to allow an arbitrary action to be performed. Then I rewrote the select/poll implementation to use event queueing to avoid rescanning descriptors that had not changed - and restructured the loops to be rather more efficient. This approach doesn't need any changes to driver poll routines, it doesn't need backwards mapping struct files. It should be fairly easy to implement a /dev/poll mechanism using this, although I haven't yet. Yes, the change to wait queues has a slight cost, but it isn't great and the main part of it only happens if you actually sleep. Performance graphs and the lmbench derived test programs I used are at http://www.purplet.demon.co.uk/linux/select/ (bounce in and out of the index page 'cos the next and prev buttons aren't wired up :-) ) Oh, and I updated this patch for 2.4.0-test9. Comments and opinions are, as always, welcome :-). Mike select.patch
RE: Linux's implementation of poll() not scalable?
Here's something I did last year and then put on ice, partly through lack of time and partly because I thought I'd pick it up for 2.5. All this talk of event queues misses one thing: we already have an event queue mechanism. They're called wait queues. The only problem is that the only on-event action possible is to wake the process (assuming it was asleep in the first place). This patch firstly extends the wait queue mechanism to allow an arbitrary action to be performed. Then I rewrote the select/poll implementation to use event queueing to avoid rescanning descriptors that had not changed - and restructured the loops to be rather more efficient. This approach doesn't need any changes to driver poll routines, it doesn't need backwards mapping struct files. It should be fairly easy to implement a /dev/poll mechanism using this, although I haven't yet. Yes, the change to wait queues has a slight cost, but it isn't great and the main part of it only happens if you actually sleep. Performance graphs and the lmbench derived test programs I used are at http://www.purplet.demon.co.uk/linux/select/ (bounce in and out of the index page 'cos the next and prev buttons aren't wired up :-) ) Oh, and I updated this patch for 2.4.0-test9. Comments and opinions are, as always, welcome :-). Mike select.patch
RE: cannot connect to linuxtoday.com 80 with test9-pre9
> Right you are, both of you. I guess was confusing 'route' with > 'interface' and didn't think of using multiple routes like that. It > would be a kludge but whatever gets the job done.. No more than some of the other route attributes like window, rtt, mtu, ssthresh etc. Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: cannot connect to linuxtoday.com 80 with test9-pre9
> [Mike Jagdis] > > Is there anyway that we could make ECN enable/disable a flag on a route? > > Would it help? It seems to me that typically, your busiest, best- > connected routes are the ones where you could derive the most benefit > from ECN -- and those same routes are where you are likely to find the > most anti-ECN firewalls. > > In other words, being able to just turn on ECN for localhost and your > internal network isn't likely to be terribly useful. Being able to turn ECN on/off for specific routes would be very useful. Currently we have to turn ECN off for systems connected to the Internet because there are bad routers out there. But I know some routes are ok and want the benefit of ECN on them. In future we should expect to have a situation where increasingly large parts of the Internet are ECN clean so we would want ECN on by default but be able to override it for specific routes that are known to fail. Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: cannot connect to linuxtoday.com 80 with test9-pre9
[Mike Jagdis] Is there anyway that we could make ECN enable/disable a flag on a route? Would it help? It seems to me that typically, your busiest, best- connected routes are the ones where you could derive the most benefit from ECN -- and those same routes are where you are likely to find the most anti-ECN firewalls. In other words, being able to just turn on ECN for localhost and your internal network isn't likely to be terribly useful. Being able to turn ECN on/off for specific routes would be very useful. Currently we have to turn ECN off for systems connected to the Internet because there are bad routers out there. But I know some routes are ok and want the benefit of ECN on them. In future we should expect to have a situation where increasingly large parts of the Internet are ECN clean so we would want ECN on by default but be able to override it for specific routes that are known to fail. Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: cannot connect to linuxtoday.com 80 with test9-pre9
> More with their firewall. But try > > echo 0 > /proc/sys/net/ipv4/tcp_ecn Is there anyway that we could make ECN enable/disable a flag on a route? Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: cannot connect to linuxtoday.com 80 with test9-pre9
More with their firewall. But try echo 0 /proc/sys/net/ipv4/tcp_ecn Is there anyway that we could make ECN enable/disable a flag on a route? Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Availability of kdb
> Q: Then why isn't kdb in the kernel? > A: Uh... More to the point, why don't the people that want a kernel debugger maintain kdb and simply drop in the patch when they need it? If Jeff releases his debugger will anyone care enough to maintain it? Less talk, more action methinks :-). Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Availability of kdb
Q: Then why isn't kdb in the kernel? A: Uh... More to the point, why don't the people that want a kernel debugger maintain kdb and simply drop in the patch when they need it? If Jeff releases his debugger will anyone care enough to maintain it? Less talk, more action methinks :-). Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
> What IS this urge to be handicapped > when trying to debug the most important pieces of what gets > delivered on the distribution CDROMs. Is it, "I'm so hairy chested > that I can code with one metaphorical arm tied behind my > equally cliched back?" There are those that like to visualize things and there are those that like to experience them. Neither is _necessarily_ wrong but Linux tends to have more of the former, and the latter have yet to write what they consider to be a good kernel debugger. (Yes, a debugger is a tool for _experiencing_ not a tool for _visualizing_) > A good debugger is a very > good leveraging agent. I can cut a 2x4 with a largish pocket knife, > in theory. (I have never wasted the time.) In a pinch I have cut a > 2X4 with a hand saw. I can see that if I wanted to do this for any > serious work power tools are required. The same logic seems > to fall into the programming realm. I disagree. No one here is dumb enough to use a wholely inappropriate tool for a particular task. But using a debugger is often (but not always) like sawing bits off your 2x4 until it happens to fit the gap. What you need to do is to understand the problem parameters, measure them, mark your 2x4, then cut using whatever tool is best suited to the job. In woodwork the results tend to be superior :-) Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
What IS this urge to be handicapped when trying to debug the most important pieces of what gets delivered on the distribution CDROMs. Is it, "I'm so hairy chested that I can code with one metaphorical arm tied behind my equally cliched back?" There are those that like to visualize things and there are those that like to experience them. Neither is _necessarily_ wrong but Linux tends to have more of the former, and the latter have yet to write what they consider to be a good kernel debugger. (Yes, a debugger is a tool for _experiencing_ not a tool for _visualizing_) A good debugger is a very good leveraging agent. I can cut a 2x4 with a largish pocket knife, in theory. (I have never wasted the time.) In a pinch I have cut a 2X4 with a hand saw. I can see that if I wanted to do this for any serious work power tools are required. The same logic seems to fall into the programming realm. I disagree. No one here is dumb enough to use a wholely inappropriate tool for a particular task. But using a debugger is often (but not always) like sawing bits off your 2x4 until it happens to fit the gap. What you need to do is to understand the problem parameters, measure them, mark your 2x4, then cut using whatever tool is best suited to the job. In woodwork the results tend to be superior :-) Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
