• Quality of digital signals

    I have seen many times people thinking that a signal has better quality if it's in digital form rather than in analog form, yet this is false. When you convert an analog signal to a digital format, you always lose quality because you are converting a continuous signal to a discrete one. Let's see a little example: Suppose we want to digitize a 20KHz analog audio signal so that we can store it on disk.

  • Linker's link sets

    I don't know about other linkers, but GNU ld provides a very useful feature: link sets. A link set is a list of symbols constructed during link time which can then be inspected in regular code. This is very interesting in situations when you want to initialize several subsystems from a centralized place but don't know which of these will be available; that is, you don't know which ones will be in the final binary.

  • Interface to change NFS exports

    While adding NFS support to tmpfs, I found how NetBSD currently manages NFS exports from userland. The interface is, IMHO, scary. As NetBSD aims for clean code and design, it must be fixed. See my mail to the tech-kern@ mailing list for more details on the issue and a preliminary patch.

  • tmpfs: Project merged into NetBSD

    After listening to many queries from developers asking when tmpfs could be integrated into NetBSD, I finally imported the code into the CVS repository. I'm really happy about this :-) Development will be simplified from now on and it will be a lot easier for interested parties to test the code. Please read the announcement for more information. I'd like to comment now some of the improvements I've been doing during the past days, which mostly addressed optimization.

  • NFS file handles

    NFS uses a structure called a file handle to uniquely identify exported files. When a client requests to access a file, the server constructs a file handle that identifies it; from this point on, this identifier will be used in all communications between the server and the client to access that specific file. (Look at the fs_vptofh and fs_fhtovp hooks in NetBSD's VFS layer to see how this mapping works.)

  • FFS, LFS and MFS

    The designers of the Fast File System (FFS) organized it in two different layers aiming for flexibility and code reuse; this happened in 4.4BSD (or maybe earlier, I don't know for sure). The upper layer communicates with the VFS and vnode code while the lower layer accesses the underlying devices and only receives requests from the upper layer. It goes like this: VFS/vnode calls <-> FFS upper layer <-> FFS lower layer <-> backing device

  • SoC: The end

    So... the deadline for Google's Summer of Code 2005 program arrived some time between yesterday and today (don't know exactly due to timezones). The final results from my side: a functional memory file-system (not efficient yet) for NetBSD named tmpfs, as well as the beginnings of a book/article on file-system development under NetBSD. As regards the file-system itself, its code can be found in the CVS repository. Despite it has some bugs and misfeatures, it is functional from the user's point of view.