看下当年Linus要做Linux时写的Email

What would you like to see most in minix?

选项

 30 的帖子 1 - 25 - 全部折叠  -  将所有内容翻译成中文（简体）  后一页 >

  Linus Benedict Torvalds  查看个人资料   翻译成中文（简体） 更多选项 1991年8月26日, 下午2时12分

Hello everybody out there using minix - 

I'm doing a (free) operating system (just a hobby, won't be big and 
professional like gnu) for 386(486) AT clones.  This has been brewing 
since april, and is starting to get ready.  I'd like any feedback on 
things people like/dislike in minix, as my OS resembles it somewhat 
(same physical layout of the file-system (due to practical reasons) 
among other things). 

I've currently ported bash(1.08) and gcc(1.40), and things seem to work. 
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 :-) 

                Linus ([e-mail]) 

PS.  Yes - it's free of any minix code, and it has a multi-threaded fs. 
It is NOT protable (uses 386 task switching etc), and it probably never 
will support anything other than AT-harddisks, as that's all I have :-(. 

 

   

  Jyrki Kuoppala  查看个人资料   翻译成中文（简体） 更多选项 1991年8月26日, 下午2时26分

In article <[e-mail]>, torvalds@klaava (Linus Benedict Torvalds) writes: 

>I've currently ported bash(1.08) and gcc(1.40), and things seem to work. 
>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 :-) 

Tell us more!  Does it need a MMU? 

>PS.  Yes - it's free of any minix code, and it has a multi-threaded fs. 
>It is NOT protable (uses 386 task switching etc) 

How much of it is in C?  What difficulties will there be in porting? 
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 
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. 

//Jyrki 

 

   

  Linus Benedict Torvalds  查看个人资料   翻译成中文（简体） 更多选项 1991年8月26日, 下午8时51分

In article <[e-mail]> [e-mail] (Jyrki Kuoppala) writes: 
>> [re: my post about my new OS] 

>Tell us more!  Does it need a MMU? 

Yes, it needs a MMU (sorry everybody), and it specifically needs a 
386/486 MMU (see later). 

>>PS.  Yes - it's free of any minix code, and it has a multi-threaded fs. 
>>It is NOT protable (uses 386 task switching etc) 

>How much of it is in C?  What difficulties will there be in porting? 
>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). 

Simply, I'd say that porting is impossible.  It's mostly in C, but most 
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__ 
directive, so that I wouldn't need so much assembly language objects. 
Some of my "C"-files (specifically mm.c) are almost as much assembler as 
C. It would be "interesting" even to port it to another compiler (though 
why anybody would want to use anything other than gcc is a mystery). 

Unlike minix, I also happen to LIKE interrupts, so interrupts 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?).  All in all it's a porters nightmare. 

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

Most of these seem possible (the tty structure already has stubs for 
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 ([e-mail]) 

PS. To make things really clear - yes I can run gcc on it, and bash, and 
most of the gnu [bin/file]utilities, but it's not very debugged, and the 
library is really minimal. It doesn't even support floppy-disks yet. It 
won't be ready for distribution for a couple of months. Even then it 
probably won't be able to do much more than minix, and much less in some 
respects. It will be free though (probably under gnu-license or similar). 

 

   

  Peter Holzer  查看个人资料   翻译成中文（简体） 更多选项 1991年8月27日, 上午1时42分

[e-mail] (Jyrki Kuoppala) writes: 
>In article <[e-mail]>, 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. 

On a lower level: 

I don't like the chmem mechanism of Minix. Processes should start with 
a minimal size and grow as they need to until they run out of RAM or 
disk space. Paging to disk would be nice, too. 

If your OS is message based I would like to have arbitrarily large 
messages. They could be implemented efficiently by mapping the pages 
into the receivers address space (or just passing a pointer on 68k 
systems without MMU). Oh, yes, and the addressing scheme for messages 
should be different than in Minix. Messages should not be sent to 
process slot numbers, but to ports. That way, user processes can use 
messages, too, and it is easier to add your own servers. 

PS: I am very interested in this OS. I have already thought of writing 
my own OS, but decided I wouldn't have the time to write everything from 
scratch. But I guess I could find the time to help raising a baby 
OS :-) 
-- 
|    _  | Peter J. Holzer                       | Think of it   | 
| |_|_) | Technical University Vienna           | as evolution  | 
| | |   | Dept. for Real-Time Systems           | in action!    | 
| __/   | [e-mail]                 |     Tony Rand | 

 

   

  James da Silva  查看个人资料   翻译成中文（简体） 更多选项 1991年8月27日, 上午2时02分

In article <[e-mail]> [e-mail] (Linus Benedict Torvalds) writes: 

>Unlike minix, I also happen to LIKE interrupts, so interrupts 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?). 

Sure.  For one example, Alessandro Forin's Mach SCSI adapter drivers are 
written this way.  A comment from his code: 

/* 
 * This layer works based on small simple 'scripts' that are installed 
 * at the start of the command and drive the chip to completion. 
 * The idea comes from the specs of the NCR 53C700 'script' processor. 
 * 
 * There are various reasons for this, mainly 
 * - Performance: identify the common (successful) path, and follow it; 
 *   at interrupt time no code is needed to find the current status 
 * - Code size: it should be easy to compact common operations 
 * - Adaptability: the code skeleton should adapt to different chips without 
 *   terrible complications. 
 * - Error handling: and it is easy to modify the actions performed 
 *   by the scripts to cope with strange but well identified sequences 
 * 
 */ 

An interesting way to write a device driver.  I believe this is a very old 
technique, too. 

Good luck on your OS project, it sounds like a lot of fun. 
Jaime 
........................................................................... 
: domain: [e-mail]                                 James da Silva 
: path:   uunet!mimsy!jds                   Systems Design & Analysis Group 

 

   

  Adam David  查看个人资料   翻译成中文（简体） 更多选项 1991年8月27日, 下午1时12分

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

-- 
Adam David. 
([e-mail]) 

 

   

  Alan Barclay  查看个人资料   翻译成中文（简体） 更多选项 1991年8月28日, 上午5时04分

In article <[e-mail]> [e-mail] (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? 
-- 
  Alan Barclay 
  iT                                |        E-mail : [e-mail] 
  Barker Lane                       |        BANG-STYLE : .....!ukc!ukpoit!alan 
  CHESTERFIELD S40 1DY              |        VOICE : [phone] 

 

   

  Linus Benedict Torvalds  查看个人资料   翻译成中文（简体） 更多选项 1991年8月28日, 下午9时01分

In article <[e-mail]> [e-mail] (Alan Barclay) writes: 
>In article <[e-mail]> [e-mail] (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? 

I'm afraid that is 64 tasks max (and one is used as swapper), no matter 
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