In my MAC tree, I add an additional:
struct mbuf *aux; /* extra data buffer; ipsec/others */
+ struct mac label; /* label of data in packet */
};
As we move towards more generalized access control, it would similarly be
nice to have a place to 'hang' a
Title: Free Rate Quote
"Refinance Your
Current Mortgage While Rates Are LOW!!"
HOME EQUITY LOANS *** JUMBO LOANS *** HOME IMPROVEMENT LOANS ***
DEBT CONSOLIDATION LOANS *** REFINANCE LOANS *** ALL ARE AVAILABLE TO YOU *** RATES AS LOW AS
3.95%
Mortgage
On Fri, 16 Nov 2001, Luigi Rizzo wrote:
> > so far there hasn't been a lot of suggestion as to how the goal can be
> > achieved however..
>
> i actually suggested one i.e. have explicit pointers
> to metadata area(s) in the pkthdr. I think you forget the
> most fundamental feature which is per
On Fri, 16 Nov 2001, Garrett Wollman wrote:
> <
>said:
>
> > (and anyhow Garrett got rid of the 'static' uses
> > of mbufs, not 'travelling' 'per packet' uses..)
>
> Only because I did not have the time or stomach then to introduce
> `struct packet' everywhere. All of the queueing and metad
ok, so how would you envision it? example?
Adding fields to the pkthdr? (and flags to say
what they are used for).
A pointer to route,
(maybe the route in ip_forward() can be dynamically allocated on the
stack, I'm not sure yet)
A pointer to a sockaddr, with a flag to say if it's for
'fwd' use
Hello all,
Sounds like a silly place to post this but...here goes. I'm getting errors
compiling cvsup from ports. The ports tree installed is the default coming
with the 11/12/01 snapshot. I want would use CVS, but I don't know how (and
yet I call my self a computer science student). It com
< said:
> (and anyhow Garrett got rid of the 'static' uses
> of mbufs, not 'travelling' 'per packet' uses..)
Only because I did not have the time or stomach then to introduce
`struct packet' everywhere. All of the queueing and metadata crap
should be pulled out of mbufs and put into a higher-le
> so far there hasn't been a lot of suggestion as to how the goal can be
> achieved however..
i actually suggested one i.e. have explicit pointers
to metadata area(s) in the pkthdr. I think you forget the
most fundamental feature which is performance.
This is way more important than flexibility i
On Fri, 16 Nov 2001, Luigi Rizzo wrote:
> On Fri, Nov 16, 2001 at 04:02:51PM -0800, Peter Wemm wrote:
>
> > it. MT_DUMMYNET must die, not be propagated elsewhere.
>
> i agree!
>
> cheers
> luigi
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-curr
Alfred Perlstein wrote:
>
> * Peter Wemm <[EMAIL PROTECTED]> [06 18:02] wrote:
> > Julian Elischer wrote:
> > [..]
> > > What is needed is obviously a 'per packet' storage location
> > > for those things, defined in a "per protocol family" manner.
> > >
> > > Luigi has already tried this sche
* Julian Elischer <[EMAIL PROTECTED]> [06 18:20] wrote:
>
> On Fri, 16 Nov 2001, Jonathan Lemon wrote:
>
> > Um, no please. MT_DUMMYNET is a bad hack that should be removed
> > (and which I've partly done in one of my trees). I would rather
> > not perpetuate this, it causes more problems
Well I don't care exactly how we do it but we need to
figure out a way of storing such metadata along with packets.
and it needs to be queueable along with the packets..
(sounds like an mbuf to me but if you have a better idea.)
(and anyhow Garrett got rid of the 'static' uses
of mbufs, not 't
On Fri, 16 Nov 2001, Jonathan Lemon wrote:
> In article [EMAIL PROTECTED]> you write:
> >As another example, the ipfw code uses a couple of static
> >variables too, in the 'fwd' code amongst other places..
> >
> >What is needed is obviously a 'per packet' storage location
> >for those things,
* Peter Wemm <[EMAIL PROTECTED]> [06 18:02] wrote:
> Julian Elischer wrote:
> [..]
> > What is needed is obviously a 'per packet' storage location
> > for those things, defined in a "per protocol family" manner.
> >
> > Luigi has already tried this scheme by defining a
> > dummynet specific
On Fri, Nov 16, 2001 at 04:02:51PM -0800, Peter Wemm wrote:
> it. MT_DUMMYNET must die, not be propagated elsewhere.
i agree!
cheers
luigi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
struct pkthdr already has a field (struct mbuf *aux)
which i think is used to store info per-packet
state by ipsec, at least according to the comment
(my dummynet hack predated this, i would have used
this field if it had been available at the time).
So this field could be used to access the metad
In article [EMAIL PROTECTED]> you write:
>As another example, the ipfw code uses a couple of static
>variables too, in the 'fwd' code amongst other places..
>
>What is needed is obviously a 'per packet' storage location
>for those things, defined in a "per protocol family" manner.
>
>Luigi has al
Julian Elischer wrote:
[..]
> What is needed is obviously a 'per packet' storage location
> for those things, defined in a "per protocol family" manner.
>
> Luigi has already tried this scheme by defining a
> dummynet specific mbuf type that can be prepended to the
> front of packets. What I s
For work related erasons I've been in the IP stack
(basically just IP actually) recently. It's obvious
that there are re-entrancy problems there.
Here are two examples..
Routed packets:
a packet that is routed, uses a single static 'route' entry...
(In ip_input.c)
Right next to it is a sockadd
> It's not the BIOS failing it...
>
> The BTX bootstrap loader V 1.00 detects the keyboard, and refuses to proceed
> without it.
The BTX loader does not detect or care about the keyboard at all.
You have another problem, and you need to supply more details before we
can be of any more assistan
On 16-Nov-01 Jim Bryant wrote:
> It's not the BIOS failing it...
>
> The BTX bootstrap loader V 1.00 detects the keyboard, and refuses to proceed
> without it.
Err, no. BTX cares zero, zilch, nada about keyboards. Can you please provide
the error message you get?
--
John Baldwin <[EMAIL PR
It's not the BIOS failing it...
The BTX bootstrap loader V 1.00 detects the keyboard, and refuses to proceed without
it.
Chris Dempsey wrote:
> Try changing the BIOS options regarding failing on all
> errors. After changing my Tyan Thunder K7 to not fail
> on keyboard failures, it was able to
On Friday 16 November 2001 07:09, Brian K. White wrote:
> testing...
>
> Brian K. White -- [EMAIL PROTECTED] --
> http://www.aljex.com/bkw/
> +[>+++[>+>+++<<-]<-]>>+.>.+.+++.-.[>+<---]
>>++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans
> Satriani
>
kindly use
what is the status of ibcs in -current ?
I'm subscribed to the list now but only have been for a few days if this is
a faq.
Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/
+[>+++[>+>+++<<-]<-]>>+.>.+.+++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACT
testing...
Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/
+[>+++[>+>+++<<-]<-]>>+.>.+.+++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current
testing...
I think I posted a note yesterday and I still don't see it, so I'm trying
again
Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/
+[>+++[>+>+++<<-]<-]>>+.>.+.+++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
subscribe freebsd-current
Thanks,
Jonathan
-
Jonathan Donaldson
Technical Marketing Engineer
Cisco Systems - Enterprise Solutions Engineering
7025 Kit Creek Rd
RTP, NC 27709
Office: 919-392-9922
Cell: 919-523-5037
Pager:
Mark, Poul-Henning,
So, what was the concensus? Should we fix this in Makefile,
or just put this as an UPDATING entry and have users manually
remove the old UUCP stuff?
On Sat, Nov 03, 2001 at 05:07:01PM +0100, Poul-Henning Kamp wrote:
>
> ===> usr.bin/tip
> install -c -s -o root -g wheel -m 5
I have a Dell Latitude C Family Model:PPX laptop. I recently upgraded
from 4.4 to 5.0 so I could use the 32-bit Xircom ethernet adapter I had.
I cvsup'd rebuilt world and kernel yesterday and these are the problems
I am having.
1. If I let the acpi module load I don't have a /dev/psm* entry fo
Hi,
I build kernel with NEWCARD from source cvsup'ed today.
Following patch is still needed for my machine & card.
Without this, the card appear as
/boot/kernel/kernel: xl0: Ethernet address: 00:00:00:00:00:00
and the card does not work.
Best regards,
--
Yoichi NAKAYAMA
At Wed, 5 Sep 2001 11:4
30 matches
Mail list logo
