What would you like to see most in minix?
选项
30 的帖子 1 - 25 - 全部折叠 - 将所有内容翻译成中文(简体) | 后一页 > |
Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and I've currently ported bash(1.08) and gcc(1.40), and things seem to work. Linus ([email protected]) PS. Yes - it's free of any minix code, and it has a multi-threaded fs. |
In article <[email protected]>, torvalds@klaava (Linus Benedict Torvalds) writes:
>I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
Tell us more! Does it need a MMU?
>This implies that I'll get something practical within a few months, and >I'd like to know what features most people would want. Any suggestions >are welcome, but I won't promise I'll implement them :-)
>PS. Yes - it's free of any minix code, and it has a multi-threaded fs.
How much of it is in C? What difficulties will there be in porting?
>It is NOT protable (uses 386 task switching etc) Nobody will believe you about non-portability ;-), and I for one would like to port it to my Amiga (Mach needs a MMU and Minix is not free). As for the features; well, pseudo ttys, BSD sockets, user-mode //Jyrki |
In article <1991Aug25.234450.22 [email protected]> j [email protected] (Jyrki Kuoppala) writes:
Yes, it needs a MMU (sorry everybody), and it specifically needs a
>> [re: my post about my new OS] >Tell us more! Does it need a MMU? 386/486 MMU (see later). >>PS. Yes - it's free of any minix code, and it has a multi-threaded fs. >How much of it is in C? What difficulties will there be in porting? people wouldn't call what I write C. It uses every conceivable feature of the 386 I could find, as it was also a project to teach me about the 386. As already mentioned, it uses a MMU, for both paging (not to disk yet) and segmentation. It's the segmentation that makes it REALLY 386 dependent (every task has a 64Mb segment for code & data - max 64 tasks in 4Gb. Anybody who needs more than 64Mb/task - tough cookies). It also uses every feature of gcc I could find, specifically the __asm__ Unlike minix, I also happen to LIKE interrupts, so interrupts are
>As for the features; well, pseudo ttys, BSD sockets, user-mode
Most of these seem possible (the tty structure already has stubs for
>filesystems (so I can say cat /dev/tcp/kruuna.helsinki.fi/finger), >window size in the tty structure, system calls capable of supporting >POSIX.1. Oh, and bsd-style long file names. window size), except maybe for the user-mode filesystems. As to POSIX, I'd be delighted to have it, but posix wants money for their papers, so that's not currently an option. In any case these are things that won't be supported for some time yet (first I'll make it a simple minix- lookalike, keyword SIMPLE). Linus ([email protected]) PS. To make things really clear - yes I can run gcc on it, and bash, and |
j [email protected] (Jyrki Kuoppala) writes:
On a lower level:
>In article <1991Aug25.205708.9 [email protected]>, torvalds@klaava (Linus Benedict Torvalds) writes: >>This implies that I'll get something practical within a few months, and >>I'd like to know what features most people would want. Any suggestions >>are welcome, but I won't promise I'll implement them :-) >As for the features; well, pseudo ttys, BSD sockets, user-mode >filesystems (so I can say cat /dev/tcp/kruuna.helsinki.fi/finger), >window size in the tty structure, system calls capable of supporting >POSIX.1. Oh, and bsd-style long file names. I don't like the chmem mechanism of Minix. Processes should start with If your OS is message based I would like to have arbitrarily large PS: I am very interested in this OS. I have already thought of writing |
In article <[email protected]> [email protected] (Linus Benedict Torvalds) writes:
>Unlike minix, I also happen to LIKE interrupts, so interrupts are
Sure. For one example, Alessandro Forin's Mach SCSI adapter drivers are
>handled without trying to hide the reason behind them (I especially like >my hard-disk-driver. Anybody else make interrupts drive a state- >machine?). written this way. A comment from his code: /* An interesting way to write a device driver. I believe this is a very old Good luck on your OS project, it sounds like a lot of fun. |
One of the things that really bugs me about minix is the way device drivers
have to be compiled into the kernel. So, how about doing some sensible installable device driver code (same goes for minix 2.0 whenever). -- |
In article <[email protected]> [email protected] (Linus Benedict Torvalds) writes:
>yet) and segmentation. It's the segmentation that makes it REALLY 386
Is that max 64 64Mb tasks or max 64 tasks no matter what their size?
>dependent (every task has a 64Mb segment for code & data - max 64 tasks >in 4Gb. Anybody who needs more than 64Mb/task - tough cookies). -- Alan Barclay iT | E-mail : a [email protected] Barker Lane | BANG-STYLE : .....!ukc!ukpoit!alan CHESTERFIELD S40 1DY | VOICE : +44 246 214241 |
In article <1991Aug27.143432.10 [email protected]> a [email protected] (Alan Barclay) writes:
I'm afraid that is 64 tasks max (and one is used as swapper), no matter
>In article <1991Aug26.110602.19 [email protected]> torva [email protected] (Linus Benedict Torvalds) writes: >>yet) and segmentation. It's the segmentation that makes it REALLY 386 >>dependent (every task has a 64Mb segment for code & data - max 64 tasks >>in 4Gb. Anybody who needs more than 64Mb/task - tough cookies). >Is that max 64 64Mb tasks or max 64 tasks no matter what their size? how small they should be. Fragmentation is evil - this is how it was handled. As the current opinion seems to be that 64 Mb is more than enough, but 64 tasks might be a little crowded, I'll probably change the limits be easily changed (to 32Mb/128 tasks for example) with just a recompilation of the kernel. I don't want to be on the machine when someone is spawning >64 processes, though :-) Linus |