Re: A question
On Tue, 20 Jun 2000, Alan Cox wrote: hybrid crossing between the V7 and the linux method. Like allocating a relatively small struct, but then make it an option to grow the struct by making a linked list of these structs. Given the low computative power of The struct size is fixed - I dont follow you From what I understand, using the task struct to keep track of sleeping processes, limits the number of processes the kernel can handle. If you allow a situation where the list of sleeping processes is stored in the task struct, but can also contain a pointer to another list of sleeping processes, you can increase functionality. If the number of sleeping processes is more then a certain number, you can activate the pointer and the kernel can follow the pointer like in a linked list. So you don't really use a linked list like linux does, but you use an array and when it's full, you can point to another array. I usually only do a bit of kernel module programming and I'm following the ELKS mailing in hope of learning a bit more about things like scheduling, so forgive me if what I say sound a bit stupid *grin*. Groeten, Dries
Re: A question
Alan Cox wrote: > hybrid crossing between the V7 and the linux method. Like allocating a > relatively small struct, but then make it an option to grow the struct by > making a linked list of these structs. Given the low computative power of The struct size is fixed - I dont follow you If I understand him correctly, the idea is to make the struct one node of a Btree -like construct. IE: (struct-of 2-or3-processes)(link to next struct) That way, with a minimal amount of processes (2,3,4, or 5) you would have one struct, just as you described. But, if you try to have more, the struct chain grows by another struct (2,3,4,or 5), etc... If you are crazy enough to have MANY processes, the chain would grow accordingly and so would the time necessary to traverse it. But with a small amount, (small being relative to personal taste), the response would be acceptable. -- == Never cross a Dragon, for you are crunchy and taste delicious! My Interests are: Ham Radio (N8MGU) | Opera | Theater | Sailing | Judaica
Re: A question
From what I understand, using the task struct to keep track of sleeping processes, limits the number of processes the kernel can handle. If you In a sense since wakeup is O(N) by number of processes processes, you can increase functionality. If the number of sleeping processes is more then a certain number, you can activate the pointer and the kernel can follow the pointer like in a linked list. So you don't really use a linked list like linux does, but you use an array and when it's full, you can point to another array. For ELKS it isnt worth it. For real Linux it would be (and in fact it does it all with lists)
Re: A question
various extended features (which few use) can then be easily added on a personal basis. I doubt that ELKS has ever run more than 15 processes, for instance. For reference the standard V7 builds were for about 30-60 processes (60 being a big box).
Re: A question
: For ELKS it isnt worth it. For real Linux it would be (and in fact it does : it all with lists) Although these suggestions about making extendable sleep structs are laudable, I, for one, agree with Alan. I think ELKS is a great learning tool, and should function simply. I've found that in many cases even ELKS code is too complicated. Alan has pointed this out with the #ifdef madness and other very little used options. The ELKS project should function as simple as possible, IMHO; various extended features (which few use) can then be easily added on a personal basis. I doubt that ELKS has ever run more than 15 processes, for instance. Regards, Greg
Re: A question
cases even ELKS code is too complicated. Alan has pointed this out with the #ifdef madness and other very little used options. Most of IFDEFs were there due to bugs in the source .. old code was just #if 0ed out and replaced with new one. At least that's what i did in parts of kernel i touched; Al then included whole patch (or file), without removing old code. Anyway, it was harmless. on a personal basis. I doubt that ELKS has ever run more than 15 processes, for instance. No, it probably hasn't. I had some 10 running but then again i was only testing it. If there was _any_ daemon present it would occupy another process slot, ... bye, Ab
Re: A question
Could anyone explain me what is a V7 like wakeup mechanism? Old old unix systems took the address of the thing they wanted to wait on and placed it in the task structure. Since the number of processes is pretty low its easy for the CPU to walk the process table on a wakeup checking if the 'wakeup' for this process matches the value it is given to wake. Its low on memory usage, its simple and it works low end. Later Unixes apparently started hashing them as the process sets got bigger, and Linux uses linked lists of tasks waiting on an event - relatively memory expensive but very clean and scalable - a good tradeoff for Linux a bad one for ELKS
Re: bcc Question
Scott Dudley writes: Compiling with bcc, I'm getting the error "error: initializer too complicated". It's in a function prototype. What should I look for? bcc does not like function prototypes. Try specifying the -ansi flags which tells bcc to remove the code through a prototype remover first. Al
Re: Technical question boot problem
I bet it definitely works (boot on XT drive) if one disables the onboard IDE first. The problem I see is using IDE and MFM/RLL drives at the same time, which might prove difficult. To boot XT drives on an AT+, one usually has to disable the IDE drives so that the BIOS doesn't go looking there. XT controllers usually have an extension BIOS to hook into the main BIOS boot entry point.
Re: Technical question boot problem
On Thu, 10 Jun 1999 [EMAIL PROTECTED] wrote: Hi all! I've got a 808[68] maschine with a 40 MB harddisk with MS-DOS 3.3 installed. I want to use this maschine with ELKS in future so I decided to make a backup of the disk first. Can I just move the whole disk with it's adapter card to my Pentium? I noticed that there is a xt disk driver for linux. You may have problems with your BIOS booting from the 40 MB or not making up its mind at all regarding which harddisk to use. This Linux XT driver is intended (AFAIK) for linuxes running only on XT harddrive, no IDE. (Typically som eextremely old 386SX.) Tip: If you end up booting from the 40MB, maybe you can fix things by booting from floppy. My second question is: I have got a problem with running init after ELKS boots under dosemu. It says ,,Loading init'' and just stops. What could be the cause? As a hint: When I start dosemu with xdos -A it complains that sector 1 could not be found. What does this mean? No idea. You ELKSers, please help out. Jakob
Re: Technical question boot problem
BTW: Do you, Jakob, or somebady else know, whether one has to "park" the xt-disk before shutting down the computer? The guy who gave me the xt insisted that I had to use the "park" utility that he had written for the disk before switching power off. AFAIR it "parks" the head of the disk on track 1. Is this neccessary, and if, how do I do this with linux and/or ELKS? Parking the drive is a good idea if you plan to move it around becasue I think it helps prevent dammage to the the drive when transported. I don't know that it'd make a difference if the computer is just moving around the house or something though. My solution would be to make a DOS boot disk with park on it, stick the disk in drive A, and re-boot and run park just before shutting the power off. Dan
Re: Technical question boot problem
I've got a 808[68] maschine with a 40 MB harddisk with MS-DOS 3.3 installed. I want to use this maschine with ELKS in future so I decided to make a backup of the disk first. Can I just move the whole disk with it's adapter card to my Pentium? I noticed that there is a xt disk driver for linux. I suspect that this will probably not work...but you may be lucky. XT's use jumpers or software on the card for determining hard drive parameters, where all AT class machines have this in some sort of BIOS setup. If you have a card which can be jumpered (I've got a couple like that) between XT or AT you'll be alright. Also, if your Pentium has an IDE controller on board, make sure you shut it off or it may conflict (though didn't xt and at controllers use different interupts or something??). I'd say your best bet is a 16 bit AT MFM controller card, that should work in your Pentuim for sure. Dan
Re: 0.0.76 Question.
On Sat, 29 May 1999, David Murn wrote: On Thu, 27 May 1999, Luke (boo) Farrar wrote: Is it a config option? It doesn't happen using sash, but does with ash. Probably because sash's inbuilt ls isn't using signals, so doesn't need to setup a signal handler. And why doesn't 286 protected mode stuff compile? Did it ever? Does any of it work? It seems to compile, but then the Image doesn't build properly. Luke(Boo) Farrar.
Re: 0.0.76 Question.
On Thu, 27 May 1999, Luke (boo) Farrar wrote: Is it a config option? It doesn't happen using sash, but does with ash. Probably because sash's inbuilt ls isn't using signals, so doesn't need to setup a signal handler. And why doesn't 286 protected mode stuff compile? Did it ever? I'm just shoving my networking code start across. Not fun! This is part of the reason why CVS was made. As you write your code, keep it up-to-date in the CVS tree. This way before alistair checks new code in, he's gotta make sure it'll merge cleanly with the CVS tree. Which is generally a better idea since he knows what he know how much the new code affects other parts of the code. Davey
