On Fri, May 4, 2012 at 5:10 PM, MBR <[email protected]> wrote: > Other operating systems in existence at the time Unix was being designed > required you to call different system calls depending on what device you > were trying to do I/O to. And some operating systems knew about file types > and defined the complete set of file types you could deal with - e.g. source > code, object files, linked executable, etc. If you wanted a new file type, > you had to get the people who provided the operating system (usually the > hardware vendor) to add it in the next rev of the OS. This created all > sorts of problems. > > To try to solve those problems, Thompson, Ritchie, etc. settled on the > philosophy that, to the greatest extent possible, all Unix I/O would be > treated as nothing more than a stream of bytes, with no structure imposed on > it by the operating system. So, device drivers in the kernel try to make > files in the filesystem and devices that can only do output (e.g. a > printer), etc., look the same to code in the application layer. The > philosophy that only applications should impose structure on the data, and > that the kernel should always present I/O as an undifferentiated byte stream > is one of the things that made Unix such a success. Versioning filesystems > run very much counter to the traditional Unix design philosophy. > > Mark Rosenthal
Mark, Your reasoning makes a lot of sense in the context of Unix philosophy. Thanks for this explanation. -Shankar _______________________________________________ Discuss mailing list [email protected] http://lists.blu.org/mailman/listinfo/discuss
