(In this reply, I'm very specific to the BSD kernel, which may not be appropriate in this list. If the discussion continues on this particular topic, I'll change the place.)
>>>>> On Sun, 23 Mar 2003 22:46:51 +0100, >>>>> Francis Dupont <[EMAIL PROTECTED]> said: >> => I have a major concern about the style of the API: it is at the >> socket level ([gs]etsockopt()) when it should be in the context of >> applications: >> - nobody wants to modify every applications in order to use the API >> (an unfortunately many applications can want to toggle one of the >> address selection knobs) >> - at the opposite a global knob is not flexible again. > I tend to agree, but do you have any concrete and feasible suggestion > to implement this? > => in an UNIX context, I can split the question into three parts: > where to put the information, how to manage it, how to use it. > For the place, there are two big options: Okay, and I'm mainly interested in the first two parts (particularly the second one). > - in user or proc structure, i.e., somewhere in the state of the process, > exactly like user credentials with possible sharing, etc. > - in environment variables, i.e., like RES_OPTIONS for tuning of > the resolver library via the process context. > In the second case, the obvious managing functions are [gs]etenv() but > this makes a textual form of tuning tables and knobs necessary. > In the first case, the best is to add a sysctl() like you already did > for the policy table. An inheritance rule completes this part. > There are two main ways to use the information: inside the kernel (like > the policy table or the proposed [gs]etsockopt()) or inside the standard > library (like the current resolver tuning). > Try first with the policy table (because you have already a good support > for a global one and because it is the main way to tune address selection, > i.e., I already use it on some multi-homed nodes and there are some cases > where I'd like to have a per-application policy). I've once considered similar approaches. I didn't go further at that time, because: - a sysctl-like approach would require a big change in the kernel. We'd need to modify the proc structure and one/several files under the sys/kern directory. I could not be sure if this kind of change was ever widely accepted for this particular purpose. - using environment variables seemed a good approach in terms of the impact on the kernel internal code. However, it is (possible but) not very easy to manipulate the env. variables within the kernel. I'd also like to avoid complicated string operations in the kernel. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------