(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]
--------------------------------------------------------------------
