On Fri, 26 Oct 2001, Luigi Rizzo wrote:
...
> documentation will likely see this behaviour documented. Changing it
> might introduce insidious bugs in the code -- because in reality,
> clusters are almost never shared except for those on the TCP send queue
> and for multicast packets (but who u
Hi,
Is there a way in FreeBSD to route packets based on the
destination port number? (I'm asking this on behalf of
a friend, not for myself.)
This is the setup: There are two uplinks, the first is
via a ADSL connection (ppp running on tun0, using PPPoE),
the second is via a normal ethernet int
> The M_LEADINGSPACE macro always had the line of code that would return
>the leading space even for ext_bufs commented out, suggesting that the
>code did exist in the original implementation or was intended to.
The M_LEADINGSPACE macro was introduced in rev 7.11 of mbuf.h, in
August 1988, at t
Hello fellow FreeBSD users!
Is WinXP compatible with FreeBSD / samba? I mean, with Windows 2000 pro I
always
could connect to my FreeBSD shares. But if I try to make a connection from
my Windows XP box I get the message:
The account is not allowd to connect from this station.
How does one so
Hi Bosko,
Bosko Milekic wrote:
>
> > M_LEADINGSPACE might be meant to return as you were saying. But
> > because of some reasons (maybe a lack of time to implement the
> > complete code), it behaves as we see now. For a long time, in many
> > systems, M_LEADINGSPACE had been returning writable
On Sat, Oct 27, 2001 at 03:31:48AM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote:
> M_LEADINGSPACE might be meant to return as you were saying. But
> because of some reasons (maybe a lack of time to implement the
> complete code), it behaves as we see now. For a long time, in many
> systems, M_LEAD
Hi, Bosko.
Bosko Milekic wrote:
>
> Just because M_LEADINGSPACE may be broken in the other systems does
> not mean that it should be broken in our system as well. I am against
> sacrificying good code in order to deal with the left-over stupidities
> (pardon the seemingly harsh vocabulary) in
On Fri, Oct 26, 2001 at 01:38:27PM -0400, Bosko Milekic wrote:
> On Fri, Oct 26, 2001 at 09:28:40AM -0700, Luigi Rizzo wrote:
> > Bosko, Keiichi has a valid point. The semantics of an interface
> > are described by the documentation associated with it, not by its
> > name or the Oxford Dictionary.
On Fri, Oct 26, 2001 at 09:28:40AM -0700, Luigi Rizzo wrote:
> Bosko, Keiichi has a valid point. The semantics of an interface
> are described by the documentation associated with it, not by its
> name or the Oxford Dictionary.
And what documentation would that be? Are you referring to the
[i
Bosko, Keiichi has a valid point. The semantics of an interface
are described by the documentation associated with it, not by its
name or the Oxford Dictionary.
As much as it might be misleading that M_LEADINGSPACE checks for
writability, it has probably been like this for a long time, we
have pl
On Fri, Oct 26, 2001 at 01:10:34PM +0100, David Malone wrote:
> So the M_LEADINGSPACE macro should probaly read:
>
> #define M_LEADINGSPACE(m) \
>(!M_WRITABLE(m) ? 0 : \
> (m)->m_flags
On Fri, Oct 26, 2001 at 08:47:27PM +0900, Keiichi SHIMA / ?$BEg7D0l?(B wrote:
> Right. And we will have a problem if someone changes the semantics of
> M_LEADINGSPACE. The M_LEADINGSPACE macro of Net/OpenBSD does the same
> as the current FreeBSD does, that is, returns 0 if M_EXT is set.
>
> >
On Fri, Oct 26, 2001 at 01:28:29PM +0100, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, David Malone writes:
> >
> >So the M_LEADINGSPACE macro should probaly read:
> >
> >#define M_LEADINGSPACE(m)
> > \
> > (!M_WRITABLE(m) ? 0 :
Hi Keiichi,
On Fri, Oct 26, 2001 at 08:47:27PM +0900, Keiichi SHIMA / ? wrote:
> Hi, I am one of the KAME members.
so i have a question for you -- the next step on this kind of
optimizations is to avoid that m_pullup() allocates an mbuf
when data is already contiguous and in a writable (
In message <[EMAIL PROTECTED]>, David Malone writes:
>
>So the M_LEADINGSPACE macro should probaly read:
>
>#defineM_LEADINGSPACE(m)
> \
> (!M_WRITABLE(m) ? 0 : \
> (m)->m_flags & M_EXT ?
> > When I looked at this question last year I think I found that there
> > were few enough places in the kernel which used M_LEADINGSPACE, so
> > it should be fairly easy to check them. However, I think several
> > of the uses were in KAME code.
> The patch posted first by Luigi is safe because
Hi, I am one of the KAME members.
> The only problem I can see with this tack is that we might end up
> with M_LEADINGSPACE macro which does something different to the
> same macro in {Net,Open}BSD. I guess we should check what their
> macros do at the moment.
Right. And we will have a problem
On Tue, Oct 23, 2001 at 06:57:59PM -0400, Bosko Milekic wrote:
> I believe that the correct way to deal with this issue is to have
> M_LEADINGSPACE and M_TRAILINGSPACE simply return the number of bytes
> that make up the leading space or trailing space, respectively,
> rega
On Tue, Oct 23, 2001 at 02:00:34PM -0500, Alfred Perlstein wrote:
> Yes, you're right, I was mistaken in my paranioa, however you're
> missing the fact that one may want to allocate an EXT buf and still
> have it writeable.
This is the function of M_RDONLY and M_WRITABLE framework which we
put in
John Polstra wrote:
> In article <002601c15cb4$064fb440$[EMAIL PROTECTED]>,
> Cyrille Lefevre <[EMAIL PROTECTED]> wrote:
> > "John Polstra" <[EMAIL PROTECTED]> wrote:
> > >
> > > Also, I don't feel that my patch is a hack. The entire purpose of
> > > dhclient's PREINIT phase is to put the network
Hi
Mpd-netgraph remove ngX interface at exit but I need fixed interfaces.
Is it possible to create option with which mpd will not send NGM_SHUTDOWN
message to ng_iface node.
--
Mikhail Yegorov
e-mail: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-n
21 matches
Mail list logo
