Your new "behavior" flag isn't known by vm_map_simply_entry, so
map simplification could drop the behavior setting on the floor.
I would prefer that the behavior is folded into eflags.
Overall, I agree with the direction. Behavior is correctly a map
attribute rather than an object attribute.
Your new "behavior" flag isn't known by vm_map_simply_entry, so
map simplification could drop the behavior setting on the floor.
I would prefer that the behavior is folded into eflags.
Overall, I agree with the direction. Behavior is correctly a map
attribute rather than an object attribute.
On 29-Jul-99 Andrew Gordon wrote:
>> # uname -a
>> FreeBSD john.baldwin.cx 3.2-STABLE FreeBSD 3.2-STABLE #3: Thu Jul 1
>> 21:08:59
>> EDT 1999 r...@john.baldwin.cx:/usr/source/src/sys/compile/JOHN i386
>
> Maybe your hardware has the windowed and linear buffer access modes active
> simultan
Tim Vanderhoek scribbled this message on Jul 29:
> On Thu, Jul 29, 1999 at 07:05:57PM -0400, James Howard wrote:
> >
> >
> >
> > DES tells me he has a new version (0.10) which mmap()s. It supposedly
> > cuts the run time down significantly, I do not have the numbers in front
> > of me.
>
> I d
On Thu, 29 Jul 1999, John Baldwin wrote:
>
> On 29-Jul-99 Andrew Gordon wrote:
> > On Wed, 28 Jul 1999, John Baldwin wrote:
> >> On 29-Jul-99 Andrew Gordon wrote:
> >> >
> >> > Sure. It's rather crude at present, but I've put it up at:
> >> >
> >> > http://www.arg1.demon.co.uk/vesatv.c
> >>
>
James Howard scribbled this message on Jul 29:
> On Thu, 29 Jul 1999, Tim Vanderhoek wrote:
>
> > fgetln() does a complete copy of the line buffer whenever an
> > excessively long line is found. On this point, it's hard to do better
> > without using mmap(), but mmap() has its own disadvantages.
Er, the original TAC was a BSD utility which was rewritten by Jay
Lepreau at Utah (who also happens to be my boss)... The source for it
that I have sitting around (1986) doesn't actually list a copyright,
but I'm fairly sure that we're in control of the copyright for that
version. The authors are
:of me. Unfortunetly he has not posted this version yet so I cannot
:download it and run it myself. He also says that if mmap fails, he drops
:back to stdio. This should only happen in the NFS case, the > 2G case,
:etc.
It should only be the > 2G case or the pipe case. mmap() works just fi
On Thu, Jul 29, 1999 at 07:05:57PM -0400, James Howard wrote:
>
>
>
> DES tells me he has a new version (0.10) which mmap()s. It supposedly
> cuts the run time down significantly, I do not have the numbers in front
> of me.
I do. Still far too slow. I'll work on this tomorrow, since that
see
On 29-Jul-99 Andrew Gordon wrote:
>> # uname -a
>> FreeBSD john.baldwin.cx 3.2-STABLE FreeBSD 3.2-STABLE #3: Thu Jul 1
>> 21:08:59
>> EDT 1999 [EMAIL PROTECTED]:/usr/source/src/sys/compile/JOHN i386
>
> Maybe your hardware has the windowed and linear buffer access modes active
> simultaneo
On Thu, 29 Jul 1999, Tim Vanderhoek wrote:
> fgetln() does a complete copy of the line buffer whenever an
> excessively long line is found. On this point, it's hard to do better
> without using mmap(), but mmap() has its own disadvantages. My last
> suggestion to James was to assume a worst case
Tim Vanderhoek scribbled this message on Jul 29:
> On Thu, Jul 29, 1999 at 07:05:57PM -0400, James Howard wrote:
> >
> >
> >
> > DES tells me he has a new version (0.10) which mmap()s. It supposedly
> > cuts the run time down significantly, I do not have the numbers in front
> > of me.
>
> I
On Thu, 29 Jul 1999, John Baldwin wrote:
>
> On 29-Jul-99 Andrew Gordon wrote:
> > On Wed, 28 Jul 1999, John Baldwin wrote:
> >> On 29-Jul-99 Andrew Gordon wrote:
> >> >
> >> > Sure. It's rather crude at present, but I've put it up at:
> >> >
> >> > http://www.arg1.demon.co.uk/vesatv.c
> >>
>
James Howard scribbled this message on Jul 29:
> On Thu, 29 Jul 1999, Tim Vanderhoek wrote:
>
> > fgetln() does a complete copy of the line buffer whenever an
> > excessively long line is found. On this point, it's hard to do better
> > without using mmap(), but mmap() has its own disadvantages.
Er, the original TAC was a BSD utility which was rewritten by Jay
Lepreau at Utah (who also happens to be my boss)... The source for it
that I have sitting around (1986) doesn't actually list a copyright,
but I'm fairly sure that we're in control of the copyright for that
version. The authors ar
:of me. Unfortunetly he has not posted this version yet so I cannot
:download it and run it myself. He also says that if mmap fails, he drops
:back to stdio. This should only happen in the NFS case, the > 2G case,
:etc.
It should only be the > 2G case or the pipe case. mmap() works just f
On Thu, Jul 29, 1999 at 07:05:57PM -0400, James Howard wrote:
>
>
>
> DES tells me he has a new version (0.10) which mmap()s. It supposedly
> cuts the run time down significantly, I do not have the numbers in front
> of me.
I do. Still far too slow. I'll work on this tomorrow, since that
se
On Thu, Jul 29, 1999 at 09:16:53PM +0900, Daniel C. Sobral wrote:
> > >
> > > Sorry, but a simplistic analysis like that just won't cut for grep.
> > > The algorithmic complexity is highly relevant here. Try this:
> >
> > Algorithmic complexity!?!
>
> Yup.
I'm sorry. I've read your message and
On Thu, 29 Jul 1999, Tim Vanderhoek wrote:
> fgetln() does a complete copy of the line buffer whenever an
> excessively long line is found. On this point, it's hard to do better
> without using mmap(), but mmap() has its own disadvantages. My last
> suggestion to James was to assume a worst cas
On 29-Jul-99 Andrew Gordon wrote:
> On Wed, 28 Jul 1999, John Baldwin wrote:
>> On 29-Jul-99 Andrew Gordon wrote:
>> >
>> > Sure. It's rather crude at present, but I've put it up at:
>> >
>> > http://www.arg1.demon.co.uk/vesatv.c
>>
>> My wincast tv card seemed to work w/o your patch to vesa.c
On Thu, 29 Jul 1999, Josef Karthauser wrote:
> Ok - but it's a bit misleading having both values in /etc/services..
>
> Shouldn't be:
> http 80/tcpwww www-http #World Wide Web HTTP
> http 80/udpwww www-http #World Wide Web HTTP
>
> Should be:
> htt
On Thu, Jul 29, 1999 at 09:16:53PM +0900, Daniel C. Sobral wrote:
> > >
> > > Sorry, but a simplistic analysis like that just won't cut for grep.
> > > The algorithmic complexity is highly relevant here. Try this:
> >
> > Algorithmic complexity!?!
>
> Yup.
I'm sorry. I've read your message and
On Thu, 29 Jul 1999, Rod Ebrahimi wrote:
> # make install
> "/usr/ports/Mk/bsd.port.subdir.mk", line 0: Cannot open
> /usr/ports/Mk/bsd.port.subdir.mk make: fatal errors encountered -- cannot
> continue
How old is the ports collection? Is it complete? Have you tried
re-sup'ing your collection?
The port system is great, however I have been running into trouble on one
particular machine. I receive this error when I enter the "make install"
command.
# make install
"/usr/ports/Mk/bsd.port.subdir.mk", line 0: Cannot open
/usr/ports/Mk/bsd.port.subdir.mk make: fatal errors encountered -- cann
On 29-Jul-99 Andrew Gordon wrote:
> On Wed, 28 Jul 1999, John Baldwin wrote:
>> On 29-Jul-99 Andrew Gordon wrote:
>> >
>> > Sure. It's rather crude at present, but I've put it up at:
>> >
>> > http://www.arg1.demon.co.uk/vesatv.c
>>
>> My wincast tv card seemed to work w/o your patch to vesa.
On Thu, 29 Jul 1999, Josef Karthauser wrote:
> Ok - but it's a bit misleading having both values in /etc/services..
>
> Shouldn't be:
> http 80/tcpwww www-http #World Wide Web HTTP
> http 80/udpwww www-http #World Wide Web HTTP
>
> Should be:
> ht
On Thu, 29 Jul 1999, Rod Ebrahimi wrote:
> # make install
> "/usr/ports/Mk/bsd.port.subdir.mk", line 0: Cannot open
> /usr/ports/Mk/bsd.port.subdir.mk make: fatal errors encountered -- cannot
> continue
How old is the ports collection? Is it complete? Have you tried
re-sup'ing your collection?
The port system is great, however I have been running into trouble on one
particular machine. I receive this error when I enter the "make install"
command.
# make install
"/usr/ports/Mk/bsd.port.subdir.mk", line 0: Cannot open
/usr/ports/Mk/bsd.port.subdir.mk make: fatal errors encountered -- can
Josef Karthauser wrote:
> Ok - but it's a bit misleading having both values in /etc/services..
>
> Shouldn't be:
> http 80/tcpwww www-http #World Wide Web HTTP
> http 80/udpwww www-http #World Wide Web HTTP
>
> Should be:
> http 80/tcp
:I've lost track of things:
:
:- are there a set of patches for 3.2-RELEASE that stabilize the NFS issues?
:
:- if not, should I drop back to 3.1-RELEASE, or grab a more current
: snapshot? This is for a production environment.
:
:I appreciate the feedback...
:
:--
:Brian 'you Bastard' Reichert
On Thu, Jul 29, 1999 at 12:11:39PM -0700, Doug wrote:
> Dominic Mitchell wrote:
> >
> > On Thu, Jul 29, 1999 at 09:04:20AM +0100, Josef Karthauser wrote:
> > > A question that always baffled me (I'm fairly easy to baffle) is why we've
> > > got some numbers defined as both udp and tcp when the ser
I've lost track of things:
- are there a set of patches for 3.2-RELEASE that stabilize the NFS issues?
- if not, should I drop back to 3.1-RELEASE, or grab a more current
snapshot? This is for a production environment.
I appreciate the feedback...
--
Brian 'you Bastard' Reichert
Josef Karthauser wrote:
> Ok - but it's a bit misleading having both values in /etc/services..
>
> Shouldn't be:
> http 80/tcpwww www-http #World Wide Web HTTP
> http 80/udpwww www-http #World Wide Web HTTP
>
> Should be:
> http 80/tcp
:I've lost track of things:
:
:- are there a set of patches for 3.2-RELEASE that stabilize the NFS issues?
:
:- if not, should I drop back to 3.1-RELEASE, or grab a more current
: snapshot? This is for a production environment.
:
:I appreciate the feedback...
:
:--
:Brian 'you Bastard' Reichert
Dominic Mitchell wrote:
>
> On Thu, Jul 29, 1999 at 09:04:20AM +0100, Josef Karthauser wrote:
> > A question that always baffled me (I'm fairly easy to baffle) is why we've
> > got some numbers defined as both udp and tcp when the service type is only
> > one or the other. Does anyone know?
>
> P
On Thu, Jul 29, 1999 at 12:11:39PM -0700, Doug wrote:
> Dominic Mitchell wrote:
> >
> > On Thu, Jul 29, 1999 at 09:04:20AM +0100, Josef Karthauser wrote:
> > > A question that always baffled me (I'm fairly easy to baffle) is why we've
> > > got some numbers defined as both udp and tcp when the se
:extremely well. So well, in fact, that I can have a program which
:mmap()'s a large file and continuously scans it - generating 4MB/sec of
:network traffic, with virtually no effect to the rest of the system.
Oh, clarification: continuously scans it but also calls
madvise(.
:Why? I can think of at least one instance where this is useful: using
:a file in the file system as a shared memory handle.
:
:Seems as if the programmer erroneously MADV_FREE's a file, well ... you
:only supplied the rope.
:
:-- Jason R. Thorpe
My main worry here, putting it into
I have tested this on both small and large files and it appears to work
extremely well. So well, in fact, that I can have a program which
mmap()'s a large file and continuously scans it - generating 4MB/sec of
network traffic, with virtually no effect to the rest of the system.
On Thu, 29 Jul 1999 10:52:02 -0700 (PDT)
Matthew Dillon wrote:
> Yes, we already do this, but only for OBJT_DEFAULT and OBJT_SWAP objects.
> We do not do this for file objects... it would make me rather nervous
> if we did :-)
Why? I can think of at least one instance where thi
On Thu, 29 Jul 1999 10:21:52 -0700 (PDT)
Matthew Dillon wrote:
> Shoot, it barely took 10 minutes for me to move the behavior field from
> the object to the vm map entry.
...make sure the map entries are clipped properly. It's easy to miss this
in the most common test case of advisi
On Thu, 29 Jul 1999 10:21:52 -0700 (PDT)
Matthew Dillon wrote:
> I'm testing it now along with the madvise(... MADV_DONTNEED) changes (to
> make them work on files in a reasonable way).
When I implemented MADV_DONTNEED and MADV_FREE in NetBSD (UVM):
DONTNEED: deactivate page
On Fri, 30 Jul 1999 01:50:28 +0900
"Daniel C. Sobral" wrote:
> Could you please elaborate on "permanent"? To what structure the
> information is currently attached, and what, if anything, can make
> that structure "go away", short of a reboot?
As permanent as the object ... i.e. as long as
On Thu, 29 Jul 1999 09:26:12 -0700 (PDT)
Matthew Dillon wrote:
> Yes, it will work. Oops. I do see one problem though... if you do
> this the underlying file object will be marked for sequential operation
> even after the grep (in this case) exits. That is, an madvise() of
>
I've lost track of things:
- are there a set of patches for 3.2-RELEASE that stabilize the NFS issues?
- if not, should I drop back to 3.1-RELEASE, or grab a more current
snapshot? This is for a production environment.
I appreciate the feedback...
--
Brian 'you Bastard' Reichert
Dominic Mitchell wrote:
>
> On Thu, Jul 29, 1999 at 09:04:20AM +0100, Josef Karthauser wrote:
> > A question that always baffled me (I'm fairly easy to baffle) is why we've
> > got some numbers defined as both udp and tcp when the service type is only
> > one or the other. Does anyone know?
>
>
:extremely well. So well, in fact, that I can have a program which
:mmap()'s a large file and continuously scans it - generating 4MB/sec of
:network traffic, with virtually no effect to the rest of the system.
Oh, clarification: continuously scans it but also calls
madvise(
:On Thu, 29 Jul 1999 10:21:52 -0700 (PDT)
: Matthew Dillon wrote:
:
: > Shoot, it barely took 10 minutes for me to move the behavior field from
: > the object to the vm map entry.
:
:...make sure the map entries are clipped properly. It's easy to miss this
:in the most common test case o
:Why? I can think of at least one instance where this is useful: using
:a file in the file system as a shared memory handle.
:
:Seems as if the programmer erroneously MADV_FREE's a file, well ... you
:only supplied the rope.
:
:-- Jason R. Thorpe <[EMAIL PROTECTED]>
My main worry he
I have tested this on both small and large files and it appears to work
extremely well. So well, in fact, that I can have a program which
mmap()'s a large file and continuously scans it - generating 4MB/sec of
network traffic, with virtually no effect to the rest of the system.
:
:On Thu, 29 Jul 1999 10:52:02 -0700 (PDT)
: Matthew Dillon wrote:
:
: > Yes, we already do this, but only for OBJT_DEFAULT and OBJT_SWAP
objects.
: > We do not do this for file objects... it would make me rather nervous
: > if we did :-)
:
:Why? I can think of at least one instan
On Thu, 29 Jul 1999 09:26:12 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> Yes, it will work. Oops. I do see one problem though... if you do
> this the underlying file object will be marked for sequential operation
> even after the grep (in this case) exits. That is,
On Fri, 30 Jul 1999 01:50:28 +0900
"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
> Could you please elaborate on "permanent"? To what structure the
> information is currently attached, and what, if anything, can make
> that structure "go away", short of a reboot?
As permanent as the object
On Thu, 29 Jul 1999 10:21:52 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> I'm testing it now along with the madvise(... MADV_DONTNEED) changes (to
> make them work on files in a reasonable way).
When I implemented MADV_DONTNEED and MADV_FREE in NetBSD (UVM):
DONTN
On Thu, 29 Jul 1999 10:21:52 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> Shoot, it barely took 10 minutes for me to move the behavior field from
> the object to the vm map entry.
...make sure the map entries are clipped properly. It's easy to miss this
in the most common
On Thu, 29 Jul 1999 10:52:02 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> Yes, we already do this, but only for OBJT_DEFAULT and OBJT_SWAP objects.
> We do not do this for file objects... it would make me rather nervous
> if we did :-)
Why? I can think of at least on
:When I implemented MADV_DONTNEED and MADV_FREE in NetBSD (UVM):
:
: DONTNEED: deactivate pages
There are some medium sized problems with doing this under FreeBSD, mainly
that this will cause the pages to recycle through the inactive and cache
queues. Without anything to bump
Shoot, it barely took 10 minutes for me to move the behavior field from
the object to the vm map entry.
I'm testing it now along with the madvise(... MADV_DONTNEED) changes (to
make them work on files in a reasonable way).
This will be current-only, though I suppose the map ch
:On Thu, 29 Jul 1999 10:21:52 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
: > Shoot, it barely took 10 minutes for me to move the behavior field from
: > the object to the vm map entry.
:
:...make sure the map entries are clipped properly. It's easy to miss this
:in the mos
:
:On Thu, 29 Jul 1999 10:52:02 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
: > Yes, we already do this, but only for OBJT_DEFAULT and OBJT_SWAP objects.
: > We do not do this for file objects... it would make me rather nervous
: > if we did :-)
:
:Why? I can think of
:On Fri, 30 Jul 1999 01:50:28 +0900
: "Daniel C. Sobral" wrote:
:
: > Could you please elaborate on "permanent"? To what structure the
: > information is currently attached, and what, if anything, can make
: > that structure "go away", short of a reboot?
:
:As permanent as the object ... i.e. as
:When I implemented MADV_DONTNEED and MADV_FREE in NetBSD (UVM):
:
: DONTNEED: deactivate pages
There are some medium sized problems with doing this under FreeBSD, mainly
that this will cause the pages to recycle through the inactive and cache
queues. Without anything to bum
Matthew Dillon wrote:
>
> Yes, it will work. Oops. I do see one problem though... if you do
> this the underlying file object will be marked for sequential operation
> even after the grep (in this case) exits. That is, an madvise() of
> MADV_NORMAL, SEQUENTIAL, or RANDOM appears
Shoot, it barely took 10 minutes for me to move the behavior field from
the object to the vm map entry.
I'm testing it now along with the madvise(... MADV_DONTNEED) changes (to
make them work on files in a reasonable way).
This will be current-only, though I suppose the map c
:So it works, then? GNU grep has this #ifdef'ed out, with a comment
:about it impacting negatively on performance on BSD 4.1. I recall
:some rants on this subject a couple of years ago... If it is
:working, I'd like to change that 0 to 1 in our tree.
:
:--
:Daniel C. Sobral (
> > My major Duh!! If Christos sees this thread, my apologies.
>
> David, I was trying to be helpful; sorry if my msg came across wrong.
^
Not in the least. I was being stupid and that's all. I'm certainly not
mad about anythi
:On Fri, 30 Jul 1999 01:50:28 +0900
: "Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
:
: > Could you please elaborate on "permanent"? To what structure the
: > information is currently attached, and what, if anything, can make
: > that structure "go away", short of a reboot?
:
:As permanent as th
Matthew Dillon wrote:
>
> Yes, it will work. Oops. I do see one problem though... if you do
> this the underlying file object will be marked for sequential operation
> even after the grep (in this case) exits. That is, an madvise() of
> MADV_NORMAL, SEQUENTIAL, or RANDOM appear
I ran screaming into the woods last year from trying to grok VOP_foo. The
prospect of a rewrite fills me with warmth and fuzziness. I hereby volunteer
to maintain the VOP(9) man pages and to flesh out my notes into a big, beefy
FS-implementer's Guide to the new VOP_foo. All the coders have to do
I would like to change the IP address (netmask, gateway etc.) of an Interface
(eg. fxp0) from within my C source code.
1. Is this possible to do without the SIOC ioctl call? (i am already in the
kernel).
2. Which structure and which member should I write the new information to
(ifaddr?)?
Thanks
:So it works, then? GNU grep has this #ifdef'ed out, with a comment
:about it impacting negatively on performance on BSD 4.1. I recall
:some rants on this subject a couple of years ago... If it is
:working, I'd like to change that 0 to 1 in our tree.
:
:--
:Daniel C. Sobral
> > My major Duh!! If Christos sees this thread, my apologies.
>
> David, I was trying to be helpful; sorry if my msg came across wrong.
^
Not in the least. I was being stupid and that's all. I'm certainly not
mad about anyth
I ran screaming into the woods last year from trying to grok VOP_foo. The
prospect of a rewrite fills me with warmth and fuzziness. I hereby volunteer
to maintain the VOP(9) man pages and to flesh out my notes into a big, beefy
FS-implementer's Guide to the new VOP_foo. All the coders have to do
Nik Clayton wrote:
>
> -hackers,
>
> Could someone who knows write/writev(2) take a quick look at docs/10512.
>
> In essence, writev(2) can fail with ENOBUFS if (and I quote from the PR)
> if you "exhaust writev'able buffer space". This doesn't mean a great
> deal to me, and I'm hoping one of y
I would like to change the IP address (netmask, gateway etc.) of an Interface
(eg. fxp0) from within my C source code.
1. Is this possible to do without the SIOC ioctl call? (i am already in the
kernel).
2. Which structure and which member should I write the new information to
(ifaddr?)?
Thanks
On Thu, 29 Jul 1999, Sheldon Hearn wrote:
>
>
> On Thu, 29 Jul 1999 00:52:27 -0400, "Brian F. Feldman" wrote:
>
> > If noone has any objections, I will commit this and MFC it in a week or so.
> >
> > --- src/usr.bin/cmp/regular.c.orig Thu Jul 29 00:43:50 1999
> > +++ src/usr.bin/cmp/regular.c
Matthew Dillon wrote:
>
> MADV_SEQUENTIAL *WILL* work. It changes the page fault
> read-behind/read-ahead. Normally the VM system reads behind a bit as well
> as reads ahead. If you set MADV_SEQUENTIAL it shifts to just doing
> read-ahead, and it does more of it.
So it works,
Nik Clayton wrote:
>
> -hackers,
>
> Could someone who knows write/writev(2) take a quick look at docs/10512.
>
> In essence, writev(2) can fail with ENOBUFS if (and I quote from the PR)
> if you "exhaust writev'able buffer space". This doesn't mean a great
> deal to me, and I'm hoping one of
On Thu, 29 Jul 1999, Sheldon Hearn wrote:
>
>
> On Thu, 29 Jul 1999 00:52:27 -0400, "Brian F. Feldman" wrote:
>
> > If noone has any objections, I will commit this and MFC it in a week or so.
> >
> > --- src/usr.bin/cmp/regular.c.orig Thu Jul 29 00:43:50 1999
> > +++ src/usr.bin/cmp/regular.
Matthew Dillon wrote:
>
> MADV_SEQUENTIAL *WILL* work. It changes the page fault
> read-behind/read-ahead. Normally the VM system reads behind a bit as well
> as reads ahead. If you set MADV_SEQUENTIAL it shifts to just doing
> read-ahead, and it does more of it.
So it works,
Hi folks,
I've come up empty-handed hunting for a constant that defines the
maximum UID supported by the system. I'm working on our passwd and
pwd_mkdb stuff and want to get rid of the artificial limitation of 65535
(USHRT_MAX) imposed in (at least) pwd_mkdb.
Have I missed a useful define, or sh
In
,
Rayson Ho wrote:
> Hi,
>
> I am not sure whether this is known to this list or
> not, but here is the URL for ordering:
>
> http://www.bsdi.com/products/evalcd/
The thing that gets my attention is the gdb with threads support.
Surely they need to provide source for the GPL gdb.
Anyone
Hi ...
When a program calls the SIOCGIFCONF ioctl and the
function ifconf in sys/net/if.c is executed, the value
that is returned in ifc.ifc_len, is that the value of
the amount of data filled in ... or can it be larger ??
Example ...
The calling process sends 1000 as the size of the buffer.
i
Hi folks,
I've come up empty-handed hunting for a constant that defines the
maximum UID supported by the system. I'm working on our passwd and
pwd_mkdb stuff and want to get rid of the artificial limitation of 65535
(USHRT_MAX) imposed in (at least) pwd_mkdb.
Have I missed a useful define, or s
Tim Vanderhoek wrote:
>
> On Thu, Jul 29, 1999 at 01:59:45AM +0900, Daniel C. Sobral wrote:
> >
> > Sorry, but a simplistic analysis like that just won't cut for grep.
> > The algorithmic complexity is highly relevant here. Try this:
>
> Algorithmic complexity!?!
Yup.
> It's a freaking grep app
In
<[EMAIL PROTECTED]>,
Rayson Ho wrote:
> Hi,
>
> I am not sure whether this is known to this list or
> not, but here is the URL for ordering:
>
> http://www.bsdi.com/products/evalcd/
The thing that gets my attention is the gdb with threads support.
Surely they need to provide source for t
On Wed, 28 Jul 1999, John Baldwin wrote:
> On 29-Jul-99 Andrew Gordon wrote:
> >
> > Sure. It's rather crude at present, but I've put it up at:
> >
> > http://www.arg1.demon.co.uk/vesatv.c
>
> My wincast tv card seemed to work w/o your patch to vesa.c. Although I don't
> think it set the resol
Hi ...
When a program calls the SIOCGIFCONF ioctl and the
function ifconf in sys/net/if.c is executed, the value
that is returned in ifc.ifc_len, is that the value of
the amount of data filled in ... or can it be larger ??
Example ...
The calling process sends 1000 as the size of the buffer.
John Reynolds~ wrote:
> Survey:
> ---
>
> 1) The sound card make and model/chipset. Please be as specific as you can
> with
>board rev numbers if possible. Please include wether the card is ISA or
> PCI.
The card is an ISA Creative Labs AWE64.
> 2) FreeBSD version(s) it was tested with
Tim Vanderhoek wrote:
>
> On Thu, Jul 29, 1999 at 01:59:45AM +0900, Daniel C. Sobral wrote:
> >
> > Sorry, but a simplistic analysis like that just won't cut for grep.
> > The algorithmic complexity is highly relevant here. Try this:
>
> Algorithmic complexity!?!
Yup.
> It's a freaking grep ap
On Wed, 28 Jul 1999, John Baldwin wrote:
> On 29-Jul-99 Andrew Gordon wrote:
> >
> > Sure. It's rather crude at present, but I've put it up at:
> >
> > http://www.arg1.demon.co.uk/vesatv.c
>
> My wincast tv card seemed to work w/o your patch to vesa.c. Although I don't
> think it set the reso
>
> > >
> > > If someone is interested to solve a problem:
> > >
> > > $ dd if=/dev/zero bs=8848 count=1 of=a 2>/dev/null
> > > $ cp a b
> > > $ cmp a b 0 0x300
> > > Segmentation fault (core dumped)
> > > $ cmp a b 0 0x200
> > > cmp: EOF on b
> > > $ cmp a b 0x300 0
> > > cmp: EOF on a
> > >
>
On Thu, 29 Jul 1999 00:52:27 -0400, "Brian F. Feldman" wrote:
> If noone has any objections, I will commit this and MFC it in a week or so.
>
> --- src/usr.bin/cmp/regular.c.origThu Jul 29 00:43:50 1999
> +++ src/usr.bin/cmp/regular.c Thu Jul 29 00:44:54 1999
|--- src/usr.bin/cmp/regular.c
On Wed, 28 Jul 1999 09:55:24 MST, "David O'Brien" wrote:
> My major Duh!! If Christos sees this thread, my apologies.
David, I was trying to be helpful; sorry if my msg came across wrong.
- ad
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of
John Reynolds~ wrote:
> Survey:
> ---
>
> 1) The sound card make and model/chipset. Please be as specific as you can with
>board rev numbers if possible. Please include wether the card is ISA or PCI.
The card is an ISA Creative Labs AWE64.
> 2) FreeBSD version(s) it was tested with. Lis
>
> > >
> > > If someone is interested to solve a problem:
> > >
> > > $ dd if=/dev/zero bs=8848 count=1 of=a 2>/dev/null
> > > $ cp a b
> > > $ cmp a b 0 0x300
> > > Segmentation fault (core dumped)
> > > $ cmp a b 0 0x200
> > > cmp: EOF on b
> > > $ cmp a b 0x300 0
> > > cmp: EOF on a
> > >
On Thu, 29 Jul 1999 00:52:27 -0400, "Brian F. Feldman" wrote:
> If noone has any objections, I will commit this and MFC it in a week or so.
>
> --- src/usr.bin/cmp/regular.c.origThu Jul 29 00:43:50 1999
> +++ src/usr.bin/cmp/regular.c Thu Jul 29 00:44:54 1999
|--- src/usr.bin/cmp/regular.
On Thu, Jul 29, 1999 at 09:04:20AM +0100, Josef Karthauser wrote:
> A question that always baffled me (I'm fairly easy to baffle) is why we've
> got some numbers defined as both udp and tcp when the service type is only
> one or the other. Does anyone know?
Probably because the IANA specifies them
On Wed, 28 Jul 1999 09:55:24 MST, "David O'Brien" wrote:
> My major Duh!! If Christos sees this thread, my apologies.
David, I was trying to be helpful; sorry if my msg came across wrong.
- ad
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of th
On Wed, 28 Jul 1999 09:55:24 MST, "David O'Brien" wrote:
> My major Duh!! If Christos sees this thread, my apologies.
Hehe, now you know how it feels to be the guy who calls you Brian. :-)
Ciao,
Sheldon.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" i
1 - 100 of 114 matches
Mail list logo
