Date: Thu, 30 Jan 1997 09:25:02 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jgreco@solaria.sol.net (Joe Greco) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, mcgovern@spoon.beta.com, hackers@freebsd.org Subject: Re: Constructive criticism (was: bashing everyone for fun and profit) Message-ID: <199701301625.JAA22068@phaeton.artisoft.com> In-Reply-To: <199701300310.VAA00309@solaria.sol.net> from "Joe Greco" at Jan 29, 97 09:10:50 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I make you a deal, Terry... you _show_ me a learning curve, and we will > see if it is ferromagnetic. :-) Hmmmm... OK. Transparent Aluminum Learning Curve #1: Describe the current overall DDI/DKI interface (including VM system API's). Describe how to write a device for it, such that the device sources will require no (or minimal) revision for use with the overall DDI/DKI interface which will be in use following the switch to devfs. Transparent Aluminum Learning Curve #2: Describe the current overall VFS module interface, starting with the VFS consumer interface at the top, and ending with the VM system API-based device interaction layer on the bottom, such that someone can write VFS modules with nearly no knowledge of FreeBSD internals, but moderate to high knowledge of FS design. Describe the theoretical basis for modules using both the VFS consumer and provider interface, instead of a system specific VM API, such that the module created will be stackable, once the layer abstraction issues that keep stacking from working above the level of agregation (as in the FFS/UFS stack) have been resolved. Transparent Aluminum Learning Curve #3: Describe the current overall support for ENPIC-type PCMCIA to ISA bridge chipsets for supplying card services. Describe the restrictions on implementation implied by the use of card services, such that a device driver can be written to operate with both PCMCIA and ISA devices, with no regard as to whether the device is a bridged PCMCIA device or a vanilla ISA device. Bonus question: describe the relationship of the current card services to the bus attach and planned PnP code changes, and its effect on the logical seperation of the functions in the device probe and attach routines. Transparent Aluminum Learning Curve #4: Describe the relationship between the kernel and utility programs such as "ps", "w", "vmstat", and so on. Place particular emphasis on providing a list of utilities which need to be rebuilt as a result of what structures changing. Describe *why* the utilities are dependent on promiscuous knowledge of kernel memory structures, and how a utility contributor can establish a similar list for a utility they plan to contribute. Bonus: describe implementation of this class of utilities with any long range plans for divorcing structure from presentation, so that the utility can be coded in such a way as to require minimal modification as these long term plans become reality. Transparent Aluminum Learning Curve #5: Describe the relationship between crt.0, ld.so, and the dlopen() family of routines. Describe the impact of this relationship on the use of library-level agregated (linker set) based constructors for pure virtual base classes (interfaces) in C++. Describe the correct way to code for maximum interoperability with the current a.out implementation, and the apparent future implementation direction, as embodied in John Polstra's "Elfkit". Transparent Aluminum Learning Curve #6: Describe why there are different tools for establishing the data structures used by the diskslice code vs. DOS partitioning, when conceptually, the only difference is the data being written. In the process, explain the utility of "/etc/disktab". Describe the interaction of these tools for adding a new disk to an existing FreeBSD system. Provide this data independent of drive controller type, drive size, physical drive geometry, or any other information which considers a drive as anything other than a linear array of sectors. Bonus: describe the operation of Bad144. Had enough? 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701301625.JAA22068>