Hi, > -----Original Message----- > From: D Cleveland [mailto:dc7525@ship.edu] > Sent: Monday, December 10, 2001 12:37 AM > To: kernelnewbies@nl.linux.org > Subject: networking and kernel > > Also how is policy and mechanism defined? I tried > finding some > explanation of what should and shouldnt be in the kernel. > Thank you very > much! I'm quoting a few parts directly from two sources that I've found an explanation _related_ to this policy/mechanism thing. For the actual text you can refer to the original docs. This one is from the free device drivers book! "Role of a device driver" section from xml.com/ldd/chapter/book/ch01.html ...Though it may appear strange to say that a driver is "flexible," we like this word because it emphasizes that the role of a device driver is providing mechanism, not policy The distinction between mechanism and policy is one of the best ideas behind the Unix design. Most programming problems can indeed be split into two parts: "what capabilities are to be provided" (the mechanism) and "how those capabilities can be used" (the policy). If the two issues are addressed by different parts of the program, or even by different programs altogether, the software package is much easier to develop and to adapt to particular needs. For example, Unix management of the graphic display is split between the X server, which knows the hardware and offers a unified interface to user programs, and the window and session managers, which implement a particular policy without knowing anything about the hardware Note the explanation here regarding what is policy and mechanism in the context of TCP/IP and FTP. As far as TCP/IP goes, FTP is a policy and socket abstraction is a mechanism. But when it comes to FTPD, the file transfer is a mechanism but the clients used for xfer is the policy. Another example is the layered structure of TCP/IP networking: the operating system offers the socket abstraction, which implements no policy regarding the data to be transferred, while different servers are in charge of the services (and their associated policies). Moreover, a server like ftpd provides the file transfer mechanism, while users can use whatever client they prefer; both command-line and graphic clients exist, and anyone can write a new user interface to transfer files. To continue with policy/mechanism in the context of a device driver . . . Where drivers are concerned, the same separation of mechanism and policy applies. The floppy driver is policy free -- its role is only to show the diskette as a continuous array of data blocks. Higher levels of the system provide policies, such as who may access the floppy drive, whether the drive is accessed directly or via a filesystem, and whether users may mount filesystems on the drive. Note this statement now ... Since different environments usually need to use hardware in different ways, it's important to be as policy free as possible When writing drivers, a programmer should pay particular attention to this fundamental concept: write kernel code to access the hardware, but don't force particular policies on the user, since different users have different needs. The driver should deal with making the hardware available, leaving all the issues about how to use the hardware to the applications. So what do you mean when you say policy free? Policy-free drivers have a number of typical characteristics. These include support for both synchronous and asynchronous operation, the ability to be opened multiple times, the ability to exploit the full capabilities of the hardware, and the lack of software layers to "simplify things" or provide policy-related operations. Drivers of this sort not only work better for their end users, but also turn out to be easier to write and maintain as well. Being policy free is actually a common target for software designers This one is from devfs README in the kernel sources documentation linux-2.4/Documentation/filesystems/devfs/README Devfs puts policy into the kernel There's already policy in the kernel. Device numbers are in fact policy (why should the kernel dictate what device numbers I use?). Face it, some policy has to be in the kernel. The real difference between device names as policy and device numbers as policy is that no one will use device numbers directly, because device numbers are devoid of meaning to humans and are ugly. At least with the devfs device names, (even though you can add your own naming scheme) some people will use the devfs-supplied names directly. This offends some people :-) Also, take a look at linux-2.4/Documentation/usb/hotplug.txt Now that was an explanation from a newbie. If the gurus out there could add to this, it would be wonderful. -hth, Giridhar -- Y Giridhar Appaji Nag I hate quotations yganag[at]yah0o<d0t>c0m Tell me what you know http://want.to.know/really? - Ralph W. Emereson > an individual are not necessarily those of UbiNetics -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ IRC Channel: irc.openprojects.net / #kernelnewbies Web Page: http://www.kernelnewbies.org/
