Serge Haouy writes: "p.244 (segmentation). You don't explain why segmentation is (or was) used. You only write later (on p.246) that it provides units for protection, but you don't explain why it is (or was) a benefit from the point of view of operating system designers rather that using paging. Actually, I don't understand why the segmentation is still used (even on a reminiscent form). I suppose it is due to compiler designers requests... but I don't have seen anywhere (neither in tanenbaum nor in Silbershatz books) a clear explanation about the benefits of pure segmentation."
In part, this may be because pure segmentation is hard to justify by comparison with paging; my understanding of the history is that it was developed in parallel, so not as something that anyone was thinking of as a superior replacement. Two pluses are that the segment table is typically smaller than a page table and that there need not be any internal fragmentation. In a world where memory was precious, both may have been important considerations. It might also make the OS simpler. I haven't gone back to check, but I believe the most sympathetic treatment of segmentation in a contemporary textbook may be in Saltzer and Kaashoek's Principles of Computer Systems Design, which would make sense given Saltzer's background.
Independent of historical systems, paging is today commonly used to implement segmentation, of course in addition to implementing the main-memory to disk interface in the storage hierarchy. The segment table (mm_struct in linux) is also needed, together with the page table, to implement segmentation, to determine which segment a virtual address is in when it is the address of a page fault. Segments are used for a host of reasons: protection, memory sharing, device memory access, memory mapped files, dynamic linking, etc.
Thanks, Seth, for this perspective. I think this is a rather different, even if related, use of the word "segmentation." For example, if two segments in this sense occupy adjoining address ranges, and their protections allow, it is possible to move a pointer off the end of one and into the other. Whereas with traditional segmentation, this would not be possible. I'm going to have to think more about how these related before I figure out what an appropriate revision to the text would be, but I appreciate your flagging it as something that needs this attention. As to the host of reasons (beyond storage hierarchy), I think I provided a similar perspective to yours at the very beginning of the virtual memory chapter.
Serge later added the following: "I've seen nowhere what is the experience of an application programmer on a system with segmentation (neither in your books, nor in the others). Perhaps could you write that segmentation is transparent for the programmer, except if he looks at the assembler code built by the compiler ?
I've read the section about segmentation in the textbook you mention. The textbook of Raphael A. Finkel (An Operating Systems Vade Mecum - see the segmentation section on the attached file.) may be clearer."
Regarding units for protection and reasons for segmentation: I would say that segments can have many different lengths while pages only come in a small number of lengths. Also, the contents of a segment are paged, so it provides a region of virtual address space with homogeneous protections that doesn't need to be mapped into memory or unmapped in its entirety.