Letters to the Editor

Readers Speak Out: Letters to the editor

This month: More info about the internal structure of file tables, DSL resources, and a price check on our recent Linux review. Plus, praise to SunWorld's editors for successfully reining in the Wild Wild Web

March  1998
[Next story]
[Table of Contents]
Sun's Site

Mail this
article to
a friend
Send letters to sweditors@sunworld.com

Feature: "Linux lines up for the enterprise" by Rick Cook

[Read Me]http://www.sunworld.com/sunworldonline/swol-01-1998/swol-01-linux.html

Linux for $2 or less


I appreciated your fair and thorough coverage of the potential of Linux for SunWorld readers. One oddity stood out: The article repeatedly quoted gross overestimates of the minimum price for a packaged Linux product. The last time I bought a Linux distribution on CD, I got two distributions (Red Hat and Debian) for $2 (yes, two dollars) apiece, plus $5 shipping and a $5 donation to the Debian project.

Now, those CDs didn't come with phone support or books, but I didn't need either. Your readers' needs may or may not match my own, but they deserve to know about the option. Another option is simply to download it all off the Internet. I've installed Linux on a laptop, which lacked CD and Ethernet interfaces, via FTP through its parallel printer port (this is called "PLIP"); it was actually easier than other methods because there was no need to configure a CD or Ethernet driver.

Nathan Myers

Feature: "Getting started with Python" by Cameron Laird and Kathryn Soraiz

[Read Me]http://www.sunworld.com/sunworldonline/swol-02-1998/swol-02-python.html

Cameron and Kathryn,

Excellent feature on Python! I really enjoyed the in-depth analysis of Python, its uses, and its current applications. I especially liked the example programs, which support the clarity and breadth of the language. Great job!

Sanford Langbart

News story: "Tcl's inventor leaves Sun to form startup" by Cameron Laird and Kathryn Soraiz

[Read Me]http://www.sunworld.com/sunworldonline/swol-02-1998/swol-02-scriptics.html

Gimme the scoop!

Cameron and Kathryn,

I just heard about John Ousterhout's new venture. I wonder what will happen to the Tcl team at Sun, and what Sun is going to do with Tcl. Any news or rumors?

James Song


Sure enough. Insiders tell me Sun will close up its Tcl shop at the beginning of this month, and Scriptics already has a chief of engineering. Sun has put up a new statement about Scriptics and Scriptics has touched up some of its Web pages already.

That's the news so far. See www.scriptics.com for more.

Cameron Laird

Letters (of praise) to the editors

Guilty by omission

To the editors:

I never give feedback on SunWorld articles, and the guilt has become too much. Since my time at Sun, and now as an independent consultant, I am indebted to you for providing timely, accurate, and informative coverage of Sun, Unix, and associated technologies.

Thank you,
Stuart Bremner

Reining in the Wild Wild Web

To the editors:

In a world gone crazy over a singing, dancing, and hard-to-navigate-or-do-anything-useful-with Wild Wild Web, accompanied by the concomitant world wide wait, your site brings a refreshing breath of change -- Web pages packed with no-nonsense, useful content.

Keep up the good work, and don't fall for the temptation to turn this site into a graphics-packed strip mall with garish neon signs and nothing useful to take away!

Looking forward to many more information-packed issues of your publication.

T.V. Raman

Connectivity: "DSL -- in depth" by Rawn Shah

[Read Me]http://www.sunworld.com/sunworldonline/swol-02-1998/swol-02-connectivity.html

DSL -- from the basics up


I'm a network engineer and I think DSL has tremendous scope with regard to connectivity issues. I'd like to know more about how it works, from the basics up.

Suraj Subramanian


You should visit the Telechoice site often. It offers DSL-related news on a weekly basis, though not so much in the way of technical details. For papers and research on DSL, Lucent's site comes to mind. To keep up technically, you should subscribe to Teleconnect magazine and go through the archives at Telecom magazine as well:

  • www.telechoice.com/xdslnewz
  • www.teledotcom.com
  • www.teleconnect.com

    Several new books on the topic are coming out soon: ADSL by Walter Goralski; ADSL/VDSL Principles by Dennis Rauschmayer; and DSL by Howard Hecht.

    I believe these should be out in March. I have yet to read or review any of them, so no comment so far. If you want to learn about DSL immediately, Video Dialtone Technology, by Daniel Minoli, touches on the subject.

    Rawn Shah

    Inside Solaris: "Fiddling around with files, part one" by Jim Mauro

    [Read Me]http://www.sunworld.com/sunworldonline/swol-02-1998/swol-02-insidesolaris.html

    What's really happening inside solaris?


    I loved your column in last month's issue, but I still have some questions about the internal structure of file tables.

    1. In the article, we know the kernel keeps a file table. Each entry contains offset and a pointer to vnode. As I understand it, separate processes can open the same file with a different offset (for example, execute two vis for the same file), so the entry in the kernel file table doesn't seem to be shared between different processes.

      If this is true, there should be one-to-one mapping between the entry in the kernel file table and the entry in u_flist which is maintained by the process table. Following this logic, why don't we get rid of u_flist and allow the process table to have a pointer to a kernel file table entry? In the kernel file table entry we can maintain a pointer for a linked list, as one process can open multiple files.

    2. An entry in a kernel file table is not shared between processes, so what is the difference between the f_count in struct file and uf_refcnt in uf_entry?

    I'm curious about what is really happening inside Solaris, and am looking forward to your answers.

    Liang Li


    Hello Liang,

    Under certain conditions, a particular file may or may not have multiple file structures associated with it. In situations where a process forks, the child process inherits the parent's open files, and thus the file structure associated with the file is shared between the parent and child process. Any file I/O done by either process manipulates the same offset field (f_offset in the file structure). This also applies to processes that issue dup(2) or dup2(2) system calls to duplicate the file descriptor. The duped file descriptor will reference the same file structure.

    The same holds true for multithreaded processes. Multiple threads in the same process all share the same file structure, so the file pointer for the same file as seen by all threads changes when one thread does a read or write.

    However, different processes that open the same file will each have their own file structure. It is possible for the same file to have multiple file structures describing it. In this situation, reads or writes to the file by one process will not affect the offset as seen by other processes that have the same file opened. The level of sharing is at the file's vnode. Every file will have one and only one vnode in the kernel.

    Your point above about doing away with the u_flist per-process open file list and simply linking directly to the processe's process structure is an interesting one. Maintaining a per-process open file list allows for per-process file flags. For example, a file opened by one process may require the file to have the close-on-exec flag to be set (true). Other processes with the same file opened may or may not want the close-on-exec behavior. If we did not maintain per-process files lists, we would not have this flexibility. There are probably other good reasons as well, I just can't think of any right now.

    Jim Mauro

    More from Liang Li:


    I still have one more question about the file table entry. In struct file_t, there's a field called f_offset. If this entry is shared by all processes that open the file, how can different processes read a file with different offsets? Don't we need to move f_offset to struct uf_entry, which is specific to each process?

    Liang Li

    Jim Mauro's reply:


    See above. Since the file structure maintains a file offset field (f_offset), it is important to be aware of the level at which the file structure is shared, so you know when a read or write by a process or thread effects the character pointer to the file (f_offset), as it is seen by other processes and/or threads.

    Thank you for your kind words about the column, and your most interesting questions. The issue you've raised is an important one, and I'll be addressing it in this month's column.

    Jim Mauro

    What did you think of this article?
    -Very worth reading
    -Worth reading
    -Not worth reading
    -Too long
    -Just right
    -Too short
    -Too technical
    -Just right
    -Not technical enough

    [Table of Contents]
    Sun's Site
    [Next story]
    Sun's Site

    [(c) Copyright  Web Publishing Inc., and IDG Communication company]

    If you have technical problems with this magazine, contact webmaster@sunworld.com

    URL: http://www.sunworld.com/swol-03-1998/swol-03-letters.html
    Last modified: