Julian,
Julian Elischer wrote:
>
> > Please look into the attached patch for FreeBSD-current.
>
> I am looking now
>
> they seem fine..
> If you wish I could commit them..
Yes. As I am not a commiter, could you commit them?
> have you tested them?
Not all parts. I have checked 1) gif over
Julian,
> Also, there was some code in the previous patch from KAME that had
> some confusion. at the bottom of encap4_input()
> can you let me know what the correct cod eshould look like..
> (keeping in mind that ipip_input() just calls rip_input() and that
> ipip_input is not compiled by defa
Keiichi SHIMA wrote:
>
> Hi all,
>
> At first, I told a lie in one point,
>
> > We had removed all the varargs input/output functions from the
> > IPv4/IPv6 stacks of the KAME repositry. These modifications will
> > make
>
> We removed all the varargs functions from the IPv4 stack (#ifdef'ed
Hi all,
At first, I told a lie in one point,
> We had removed all the varargs input/output functions from the
> IPv4/IPv6 stacks of the KAME repositry. These modifications will
> make
We removed all the varargs functions from the IPv4 stack (#ifdef'ed
for FreeBSD), but preserved for the IPv6 s
Hi all,
We had removed all the varargs input/output functions from the
IPv4/IPv6 stacks of the KAME repositry. These modifications will make
it easier to import KAME code into FreeBSD4/5. Now we are testing the
code with KAME/FreeBSD4 and it looks OK. I will soon make a patch for
FreeBSD5 and
[EMAIL PROTECTED] wrote:
| >at least we'd get rid of the d*mned warning messages!
| >Are you not aware that most of the warning messages for a normal
| >kernel compile come from the KAME code? I am on compile number 157
| >for the KSE code. (in 3 weeks)
|
| though i have no freebsd-curre
et someone else more capable in the
art of communication to proxy these discussions for you if you're
really keen to get involved in both the large scale and small scale
issues.
Thanks,
- Jordan
From: [EMAIL PROTECTED]
Subject: Re: IPV6/KAME/protosw integration cleanup
Date: Mon, 27 Aug 2
Jun-ichiro itojun Hagino wrote:
>
> >We are planning to fill your (and many freebsd hackers') requirements.
>
> - i have never heard from other people about (against) the use of
> varargs, therefore, it is misleading to say "many freebsd hackers".
Right. Sorry if other freebsd g
>We are planning to fill your (and many freebsd hackers') requirements.
just a nitpicking.
- i don't think julian is in the position to set the requirement
for freebsd. is he?
- i have never heard from other people about (against) the use of
varargs,
We are planning to fill your (and many freebsd hackers') requirements.
These plans include introducing some #ifdef clause to match freebsd's
prototypes if there is no other way to live with freebsd in peace,
though it increases our maintanance cost. (on the contrary, not
introducing #ifdef clause
>at least we'd get rid of the d*mned warning messages!
>Are you not aware that most of the warning messages for a normal
>kernel compile come from the KAME code? I am on compile number 157
>for the KSE code. (in 3 weeks)
though i have no freebsd-current box, i disagree. there are a lot
>I have still not heard any reason for the varargs here..
>except "it's needed for portability"..
>portability with WHO?
portability with other *BSD projects (NetBSD, OpenBSD, BSD/OS, MacOSX
maybe).
>BSD4.4 certainly didn't have varargs there
4.4BSD did not have pro
FWIW, sadly, Mac OS X does flirt with varargs. These seem to have
crept in via the Mach back door. I don't believe that they are
actually used anywhere, but the varargs headers are there. Our
version of the KAME stack must have pre-dated the intro of this,
because the 'bsd' side of the code
Jun-ichiro itojun Hagino wrote:
>
> >I have still not heard any reason for the varargs here..
> >except "it's needed for portability"..
> >portability with WHO?
>
> portability with other *BSD projects (NetBSD, OpenBSD, BSD/OS, MacOSX
> maybe).
are you suggesting that BSD/OS and
Keiichi SHIMA wrote:
>
> Hi,
>
> KAME had removed ipprotosw.h from the KAME source repositry (for
> FreeBSD4). Though this do not clean up the varargs functions, we
> still think this is a better (or not worst at least) comprimise in a
> current situation.
>
> Also, I had made a patch for Free
Hi,
KAME had removed ipprotosw.h from the KAME source repositry (for
FreeBSD4). Though this do not clean up the varargs functions, we
still think this is a better (or not worst at least) comprimise in a
current situation.
Also, I had made a patch for FreeBSD-CURRENT for the same purpose.
Please
On Thu, 16 Aug 2001, Julian Elischer wrote:
> On Thu, 16 Aug 2001, Bruce Evans wrote:
>
> > > I will not be doing any changes that affect them, Though I may still add
> > > the prototype definitions in protsw.h as that's a generally useful thing
> > > to do.
> >
> > I think those are the least us
On Thu, 16 Aug 2001, Bruce Evans wrote:
> > I will not be doing any changes that affect them, Though I may still add
> > the prototype definitions in protsw.h as that's a generally useful thing
> > to do.
>
> I think those are the least useful of your changes. They are certainly
> the most in
On Thu, 16 Aug 2001, Garrett Wollman wrote:
> < said:
>
> > Protosw's are still externed, so more declarations are needed, but
> > that should change.
>
> I have wanted to move the protosw[] entries into the individual
> protocols for a long time. We're already halfway there.
yes, but it is
< said:
> Protosw's are still externed, so more declarations are needed, but
> that should change.
I have wanted to move the protosw[] entries into the individual
protocols for a long time. We're already halfway there.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscri
> I will not be doing any changes that affect them, Though I may still add
> the prototype definitions in protsw.h as that's a generally useful thing
> to do.
I think those are the least useful of your changes. They are certainly
the most intrusive if the function typedefs are actually used.
Th
Firstly I would like to appologise to the KAME folks.
I think that in general they are doing a wonderful job, and
I was in a bad spot at the time and let my better judgement
get over-run by my annoyance at what I saw (still do)
as a rather poor implementation decision.
Some of the KAME folks h
On Sun, 12 Aug 2001, Julian Elischer wrote:
> Robert Watson wrote:
> >
> > It strikes me that, although some code cleanup may be called for, a week
> > is too agressive a deadline for many of them to be pushed through,
> > especially in light of the code maintenance issue on the KAME side.
>
> On Sun, 12 Aug 2001 23:31:30 -0700,
> Julian Elischer <[EMAIL PROTECTED]> said:
>> I tend to agree with itojun. Although I understand FreeBSD guys want
>> to make code from KAME cleaner in terms of FreeBSD's own point of
>> view, it will make future merge from KAME to FreeBSD harder.
Julian,
Julian Elischer wrote:
>
> > I tend to agree with itojun. Although I understand FreeBSD guys want
> > to make code from KAME cleaner in terms of FreeBSD's own point of
> > view, it will make future merge from KAME to FreeBSD harder. This is
> > a trade-off issue, but at this moment, I
>> xx_output() has never been governed by protocol switch structure
>> and therefore ther are numerous variations we see in the tree.
>> i don't see your problem at all.
>then why is it in ip6protosw?
ok, I stand corrected.
>> more #ifdef = more bug, and
>Well what is there now is plainly unacceptable
>I think that it was asked for as a VERY SHORT TERM hack.
>But it has been there a long time...
>I see no reasons so far to not make most of these changes..
well, you are ignoging our design decisions. they are all done
for reasons.
>Please note that the ip6protosw is ALSO very broken
unfortunately, you are wrong. yes, protosw is supposed to be
protocol-independent. however, due to the nature of IPv6 extension
headers (you can have infinite number of them) you can blow the kernel
stack very
Robert Watson wrote:
>
> It strikes me that, although some code cleanup may be called for, a week
> is too agressive a deadline for many of them to be pushed through,
> especially in light of the code maintenance issue on the KAME side.
I sugggest no changes in 4.x
They have had over a year for
note: I cannot respond to this address directly.
JINMEI Tatuya / 神明達哉 wrote:
>
> > On Sun, 12 Aug 2001 18:40:02 +0900,
> > [EMAIL PROTECTED] said:
>
> >> When KAME was added the mesh was less that perfect but there was so much to
> >> be done that some shortcuts needed to be
Jun-ichiro itojun Hagino wrote:
>
> >> >1/ removal of "control" argument from rip6_input and prepend control mbuf
> >> >to chain AS IT WAS DESIGNED FOR. This makes rip6_input conform to the proto
> >> >type for input. (I have not confirmed that the information in control
> >> >is a valid mbuf but
> On Sun, 12 Aug 2001 18:40:02 +0900,
> [EMAIL PROTECTED] said:
>> When KAME was added the mesh was less that perfect but there was so much to
>> be done that some shortcuts needed to be taken.
>>
>> now that time has passed some of these can be cleaned up.
>>
>> 1/ Merging ipprotosw.
>> >1/ removal of "control" argument from rip6_input and prepend control mbuf
>> >to chain AS IT WAS DESIGNED FOR. This makes rip6_input conform to the proto
>> >type for input. (I have not confirmed that the information in control
>> >is a valid mbuf but it is an mbuf pointer).
>> i don't see
It strikes me that, although some code cleanup may be called for, a week
is too agressive a deadline for many of them to be pushed through,
especially in light of the code maintenance issue on the KAME side. I
suggest that we look at a more gradual approach, as there's no rush right
now for 5.0-
Jun-ichiro itojun Hagino wrote:
>
> >Well what is there now is plainly unacceptable
> >I think that it was asked for as a VERY SHORT TERM hack.
> >But it has been there a long time...
> >I see no reasons so far to not make most of these changes..
>
> well, you are ignoging our design dec
Jun-ichiro itojun Hagino wrote:
>
> >Please note that the ip6protosw is ALSO very broken
>
> unfortunately, you are wrong. yes, protosw is supposed to be
> protocol-independent. however, due to the nature of IPv6 extension
> headers (you can have infinite number of them
36 matches
Mail list logo
