> * it's part of the dependancy chain now for a lot of packages,
>
> You are entitled to you opinion, but please don't misrepresent the
> facts. They are not part of the dependency chain for any *packages*.
Sorry if the english I used was ambiguous - I should have said "to
install packages us
In message <[EMAIL PROTECTED]> "Brian F.
Feldman" writes:
: if ((p1 = (u_char *)mmap(NULL,
: - (size_t)length, PROT_READ, MAP_SHARED, fd1, off1)) == (u_char *)MAP_FAILED)
: + (size_t)mlength, PROT_READ, MAP_SHARED, fd1, off1)) == (u_char
:*)MAP_FAILED)
: err(E
On Wed, 28 Jul 1999, Thomas David Rivers wrote:
> >
> > 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
>
:Wow, that's interesting. While I never looked at the code, I *thought* I was
:able to measure a speed boost in a certain large embedded application I'm
:working on, with adding some madvise()'s in to mmap'ed files. (Streaming
:video madvise'ed with MADV_SEQUENTIAL seemed to be slightly faster, but
>
> :Because of licensing restrictions in our product, we are unable to ship with
> :any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I
> :saw tac, and agree that it is faster for this specific use)
> :
> :Any VM people wanna pipe up and make a suggestion so that I may make
:Because of licensing restrictions in our product, we are unable to ship with
:any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I
:saw tac, and agree that it is faster for this specific use)
:
:Any VM people wanna pipe up and make a suggestion so that I may make up a
:patch?
On Wed, 28 Jul 1999, Thomas David Rivers wrote:
> >
> > 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
>
:Wow, that's interesting. While I never looked at the code, I *thought* I was
:able to measure a speed boost in a certain large embedded application I'm
:working on, with adding some madvise()'s in to mmap'ed files. (Streaming
:video madvise'ed with MADV_SEQUENTIAL seemed to be slightly faster, bu
>
> :Because of licensing restrictions in our product, we are unable to ship with
> :any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I
> :saw tac, and agree that it is faster for this specific use)
> :
> :Any VM people wanna pipe up and make a suggestion so that I may make
Because of licensing restrictions in our product, we are unable to ship with
any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I
saw tac, and agree that it is faster for this specific use)
Any VM people wanna pipe up and make a suggestion so that I may make up a
patch?
Kevi
:Because of licensing restrictions in our product, we are unable to ship with
:any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I
:saw tac, and agree that it is faster for this specific use)
:
:Any VM people wanna pipe up and make a suggestion so that I may make up a
:patch
Because of licensing restrictions in our product, we are unable to ship with
any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I
saw tac, and agree that it is faster for this specific use)
Any VM people wanna pipe up and make a suggestion so that I may make up a
patch?
Kev
According to Keith Stevenson:
> Sure, I can work on that. It would be helpful if you could include a few
> sample outputs that I could work from.
You may also want to look at the builtin stat(1) function in zsh too. 3.1.5+
only, I don't think 3.1.4 had it. BTW 3.1.6 now pretty close to release.
According to Keith Stevenson:
> Sure, I can work on that. It would be helpful if you could include a few
> sample outputs that I could work from.
You may also want to look at the builtin stat(1) function in zsh too. 3.1.5+
only, I don't think 3.1.4 had it. BTW 3.1.6 now pretty close to release.
On 29-Jul-99 Andrew Gordon wrote:
> On 28 Jul 1999, Dag-Erling Smorgrav wrote:
>
>> Andrew Gordon writes:
>> > The application for which I need this is to support capture from the bktr
>> > driver onto the screen (ie. so that you can watch TV without X). With the
>> > above hack and a small (10
:> Sheldon Hearn writes:
:> > I plan to mention in the comments for each service in /etc/services, the
:> > latest RFC describing the service.
:>
:> Good idea.
:
: H... I'm not sure what this gets us. Wouldn't it be better to
:place this kind of information in the man page that you sugg
On 26 Jul 1999, Dag-Erling Smorgrav wrote:
> Sheldon Hearn writes:
> > I plan to mention in the comments for each service in /etc/services, the
> > latest RFC describing the service.
>
> Good idea.
H... I'm not sure what this gets us. Wouldn't it be better to
place this kind of info
:On Wed, 28 Jul 1999, Nate Williams wrote:
:> >
:> > These were changes that were necessary to make ipfw readable enough that
:> > I could work with it in this area. They aren't just to clean it up, or
:> > just for change's sake. They need to stay in.
:>
:> C'mon now, re-ording the lines is *cer
On 29-Jul-99 Andrew Gordon wrote:
> On 28 Jul 1999, Dag-Erling Smorgrav wrote:
>
>> Andrew Gordon <[EMAIL PROTECTED]> writes:
>> > The application for which I need this is to support capture from the bktr
>> > driver onto the screen (ie. so that you can watch TV without X). With the
>> > above
:> Sheldon Hearn <[EMAIL PROTECTED]> writes:
:> > I plan to mention in the comments for each service in /etc/services, the
:> > latest RFC describing the service.
:>
:> Good idea.
:
: H... I'm not sure what this gets us. Wouldn't it be better to
:place this kind of information in the ma
On 28 Jul 1999, Dag-Erling Smorgrav wrote:
> Andrew Gordon writes:
> > The application for which I need this is to support capture from the bktr
> > driver onto the screen (ie. so that you can watch TV without X). With the
> > above hack and a small (100-line) program it works very nicely - far
On 26 Jul 1999, Dag-Erling Smorgrav wrote:
> Sheldon Hearn <[EMAIL PROTECTED]> writes:
> > I plan to mention in the comments for each service in /etc/services, the
> > latest RFC describing the service.
>
> Good idea.
H... I'm not sure what this gets us. Wouldn't it be better to
pla
:On Wed, 28 Jul 1999, Nate Williams wrote:
:> >
:> > These were changes that were necessary to make ipfw readable enough that
:> > I could work with it in this area. They aren't just to clean it up, or
:> > just for change's sake. They need to stay in.
:>
:> C'mon now, re-ording the lines is *ce
On Wed, 28 Jul 1999, David E. Cross wrote:
> I am wading through the portalfs and nullfs source, but I am desperately
> lost. I would love to be able to find out who would be willing to help out
> with questions. I feel I would be spamming far too many people by just
> sending
> to -hackers.
M
On Wed, 28 Jul 1999, Matthew Dillon wrote:
> Ouch. I don't think anyone understands the VOP stuff completely. It's
> a big mess -- which is why it's going to be rewritten later this year.
>
> Your best bet is to study the implementation of the UFS/FFS filesystem.
well, i'd do v9f
:> The code is *NO* more readable by you re-ordering lines and changes
:> whitespace.
:...
:
:.
Sounds like one of many arguments I've had with various people
who insist on nitpicking and critiqing to death tiny little
itsy bitsy inconsistancies that no normal person would car
On Wed, Jul 28, 1999 at 02:40:19PM -0600, Nate Williams wrote:
>
> Or is this Linux, where we don't give a rip and whatever the current
> patch does to the rest of the tree is fine, since the more code we have
> the better?
Nate, you know damn well that's not true. You're complaining about
three
:I am wading through the portalfs and nullfs source, but I am desperately
:lost. I would love to be able to find out who would be willing to help out
:with questions. I feel I would be spamming far too many people by just sending
:to -hackers. Some of the topics I am curious about are general fs
On Wed, Jul 28, 1999 at 02:42:35PM -0600, Nate Williams wrote:
>
> The code is *NO* more readable by you re-ordering lines and changes
> whitespace.
It's white!
No, dammit, it's beige!
Fuck you, I said it's white!
Beige!
White!
I dunno, I guess for some people the distinction's actually
mea
>
> 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
>
> Jean-Marc
>
I've seen a similar problem when do
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!?!
It's a freaking grep application. There is no freaking algorithmic
On 28 Jul 1999, Dag-Erling Smorgrav wrote:
> Andrew Gordon <[EMAIL PROTECTED]> writes:
> > The application for which I need this is to support capture from the bktr
> > driver onto the screen (ie. so that you can watch TV without X). With the
> > above hack and a small (100-line) program it work
I am wading through the portalfs and nullfs source, but I am desperately
lost. I would love to be able to find out who would be willing to help out
with questions. I feel I would be spamming far too many people by just sending
to -hackers. Some of the topics I am curious about are general fs-sty
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
Jean-Marc
--
Jean-Marc ZucconiPGP Key: finger j...@fre
On Wed, 28 Jul 1999, David E. Cross wrote:
> I am wading through the portalfs and nullfs source, but I am desperately
> lost. I would love to be able to find out who would be willing to help out
> with questions. I feel I would be spamming far too many people by just sending
> to -hackers.
Mig
On Wed, 28 Jul 1999, Matthew Dillon wrote:
> Ouch. I don't think anyone understands the VOP stuff completely. It's
> a big mess -- which is why it's going to be rewritten later this year.
>
> Your best bet is to study the implementation of the UFS/FFS filesystem.
well, i'd do v9
:> The code is *NO* more readable by you re-ordering lines and changes
:> whitespace.
:...
:
:.
Sounds like one of many arguments I've had with various people
who insist on nitpicking and critiqing to death tiny little
itsy bitsy inconsistancies that no normal person would ca
On Wed, Jul 28, 1999 at 02:40:19PM -0600, Nate Williams wrote:
>
> Or is this Linux, where we don't give a rip and whatever the current
> patch does to the rest of the tree is fine, since the more code we have
> the better?
Nate, you know damn well that's not true. You're complaining about
thre
:I am wading through the portalfs and nullfs source, but I am desperately
:lost. I would love to be able to find out who would be willing to help out
:with questions. I feel I would be spamming far too many people by just sending
:to -hackers. Some of the topics I am curious about are general f
On Wed, Jul 28, 1999 at 02:42:35PM -0600, Nate Williams wrote:
>
> The code is *NO* more readable by you re-ordering lines and changes
> whitespace.
It's white!
No, dammit, it's beige!
Fuck you, I said it's white!
Beige!
White!
I dunno, I guess for some people the distinction's actually
me
>
> 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
>
> Jean-Marc
>
I've seen a similar problem when d
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!?!
It's a freaking grep application. There is no freaking algorithmic
I am wading through the portalfs and nullfs source, but I am desperately
lost. I would love to be able to find out who would be willing to help out
with questions. I feel I would be spamming far too many people by just sending
to -hackers. Some of the topics I am curious about are general fs-st
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
Jean-Marc
--
Jean-Marc ZucconiPGP Key: finger [EMAIL
Wes Peters wrote:
>
> I have written man pages for aio_write, aio_error, aio_return,
> aio_cancel, aio_suspend, and lio_listio. They are in my ~ on
> freefall if anyone would like to review them. I have also edited
> aio_read.2 and aio.h to correct minor problems, if you would like
> to review t
Doug wrote:
> The more complete the feature set, the better
>off we are for my money.
Someone offering money? Quick, who's got the donations hat... :-)
Peter
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
> > > > In particular, the changes I pointed out are not 'cleanups', but style
> > > > changes.
> > >
> > > When you make code readable, it's a cleanup.
> >
> > The code is *NO* more readable by you re-ordering lines and changes
> > whitespace.
>
> This is so very objective.
That's why it consi
Wes Peters wrote:
>
> I have written man pages for aio_write, aio_error, aio_return,
> aio_cancel, aio_suspend, and lio_listio. They are in my ~ on
> freefall if anyone would like to review them. I have also edited
> aio_read.2 and aio.h to correct minor problems, if you would like
> to review
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > > > These were changes that were necessary to make ipfw readable enough
> > > > > > that
> > > > > > I could work with it in this area. They aren't just to clean it up,
> > > > > > or
> > > > > > just for change's sake. They need to stay in.
> >
> In the kernel config file you can use symbolic names for the various
> COM ports, IO_COM1, IO_COM2, and so on.
>
> These seem be defined in sys/isa/isareg.h.
>
> If you want to configure FreeBSD to boot from a serial console you have
> to set BOOT_COMCONSOLE_PORT in /etc/make.conf -- you can't
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > *rant on*
> > > > Brian, FreeBSD isn't your private playground for playing around, this is
> > > > a group project, and you gotta follow the rules, or you don't get to
> > > > play with the rest of the folks
> > >
> > > The rules don't say "le
> > > > > These were changes that were necessary to make ipfw readable enough
> > > > > that
> > > > > I could work with it in this area. They aren't just to clean it up, or
> > > > > just for change's sake. They need to stay in.
> > > >
> > > > C'mon now, re-ording the lines is *certainly* not n
> > > *rant on*
> > > Brian, FreeBSD isn't your private playground for playing around, this is
> > > a group project, and you gotta follow the rules, or you don't get to
> > > play with the rest of the folks
> >
> > The rules don't say "leave the code that you work with in a bigger mess than
>
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > These were changes that were necessary to make ipfw readable enough that
> > > > I could work with it in this area. They aren't just to clean it up, or
> > > > just for change's sake. They need to stay in.
> > >
> > > C'mon now, re-ording the line
On Wed, 28 Jul 1999, Brian F. Feldman wrote:
> On Wed, 28 Jul 1999, Nate Williams wrote:
> > >
> > > These were changes that were necessary to make ipfw readable enough that
> > > I could work with it in this area. They aren't just to clean it up, or
> > > just for change's sake. They need to sta
On Wed, Jul 28, 1999 at 04:01:10PM -0400, Brian F. Feldman wrote:
> Since you've got it in RCS, you shouldn't have any problem adding new
> features. How about a selectable display of fields, and ability to put
> them in machine-readable (read: no cut required) form? I'd suggest
> having a function
> > > These were changes that were necessary to make ipfw readable enough that
> > > I could work with it in this area. They aren't just to clean it up, or
> > > just for change's sake. They need to stay in.
> >
> > C'mon now, re-ording the lines is *certainly* not necessary to work.
>
> That's t
Doug <[EMAIL PROTECTED]> wrote:
> The more complete the feature set, the better
>off we are for my money.
Someone offering money? Quick, who's got the donations hat... :-)
Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Wed, 28 Jul 1999, Nate Williams wrote:
> >
> > These were changes that were necessary to make ipfw readable enough that
> > I could work with it in this area. They aren't just to clean it up, or
> > just for change's sake. They need to stay in.
>
> C'mon now, re-ording the lines is *certainly*
> > > > In particular, the changes I pointed out are not 'cleanups', but style
> > > > changes.
> > >
> > > When you make code readable, it's a cleanup.
> >
> > The code is *NO* more readable by you re-ordering lines and changes
> > whitespace.
>
> This is so very objective.
That's why it cons
> > > @@ -302,14 +303,15 @@
> > > struct ifnet *rif, struct ifnet *oif)
> > > {
> > > if (ip) {
> > > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct icmp *const icmp =
On Wed, 28 Jul 1999, Nate Williams wrote:
> > Index: src/sys/netinet/ip_fw.c
> > ===
> > RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> > retrieving revision 1.114
> > diff -u -r1.114 ip_fw.c
> > --- ip_fw.c 1999/06/19 18:43:28
On Tue, Jul 27, 1999 at 10:58:08PM -0700, David O'Brien wrote:
> Lets help these people out. How about adding this to 3.3's RELEASE notes
> and a pointer from our website? (maybe also
> http://www.freebsd.org/handbook/install.html)
If you can give me text, I'll mark it up and add it.
N
--
[in
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > > > These were changes that were necessary to make ipfw readable enough that
> > > > > > I could work with it in this area. They aren't just to clean it up, or
> > > > > > just for change's sake. They need to stay in.
> > > > >
> > > > > C'mon no
-hackers,
In the kernel config file you can use symbolic names for the various
COM ports, IO_COM1, IO_COM2, and so on.
These seem be defined in sys/isa/isareg.h.
If you want to configure FreeBSD to boot from a serial console you have
to set BOOT_COMCONSOLE_PORT in /etc/make.conf -- you can't us
-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 you can take a look at come up with
Since you've got it in RCS, you shouldn't have any problem adding new
features. How about a selectable display of fields, and ability to put
them in machine-readable (read: no cut required) form? I'd suggest
having a function that would printf "%s: whatever", arg1 for humans
and "whatever" for mach
> Index: src/sys/netinet/ip_fw.c
> ===
> RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> retrieving revision 1.114
> diff -u -r1.114 ip_fw.c
> --- ip_fw.c 1999/06/19 18:43:28 1.114
> +++ ip_fw.c 1999/07/28 06:29:07
> @@ -106,6
> In the kernel config file you can use symbolic names for the various
> COM ports, IO_COM1, IO_COM2, and so on.
>
> These seem be defined in sys/isa/isareg.h.
>
> If you want to configure FreeBSD to boot from a serial console you have
> to set BOOT_COMCONSOLE_PORT in /etc/make.conf -- you can'
I need help finishing it. The ipfw.8 manpage isn't quite fixed yet. When
someone will do that, it will be Ready :) But I've attached it!
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > *rant on*
> > > > Brian, FreeBSD isn't your private playground for playing around, this is
> > > > a group project, and you gotta follow the rules, or you don't get to
> > > > play with the rest of the folks
> > >
> > > The rules don't say "l
> > > > > These were changes that were necessary to make ipfw readable enough that
> > > > > I could work with it in this area. They aren't just to clean it up, or
> > > > > just for change's sake. They need to stay in.
> > > >
> > > > C'mon now, re-ording the lines is *certainly* not necessary t
> > > *rant on*
> > > Brian, FreeBSD isn't your private playground for playing around, this is
> > > a group project, and you gotta follow the rules, or you don't get to
> > > play with the rest of the folks
> >
> > The rules don't say "leave the code that you work with in a bigger mess than
I hacked this together last night. The only GNU code I looked at was the
Linux stat(1u) man page. (A man page is forthcoming, especially if there is
some interest in using this implementation.) The code is also available at
http://www.kagekaze.org/stat.c
Regards,
--Keith Stevenson--
--
Keith
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > These were changes that were necessary to make ipfw readable enough that
> > > > I could work with it in this area. They aren't just to clean it up, or
> > > > just for change's sake. They need to stay in.
> > >
> > > C'mon now, re-ording the lin
On Wed, 28 Jul 1999, Brian F. Feldman wrote:
> On Wed, 28 Jul 1999, Nate Williams wrote:
> > >
> > > These were changes that were necessary to make ipfw readable enough that
> > > I could work with it in this area. They aren't just to clean it up, or
> > > just for change's sake. They need to st
> > > > Implementing it is the easy part, making sure it's the right thing to do
> > > > is the hard part.
> > >
> > > Well, the easy part is done, except for raising limits. Look:
> > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via l
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > Implementing it is the easy part, making sure it's the right thing to do
> > > is the hard part.
> >
> > Well, the easy part is done, except for raising limits. Look:
> > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> > ipfw: 1 Deny ICMP:8.
On Wed, Jul 28, 1999 at 04:01:10PM -0400, Brian F. Feldman wrote:
> Since you've got it in RCS, you shouldn't have any problem adding new
> features. How about a selectable display of fields, and ability to put
> them in machine-readable (read: no cut required) form? I'd suggest
> having a functio
> > > These were changes that were necessary to make ipfw readable enough that
> > > I could work with it in this area. They aren't just to clean it up, or
> > > just for change's sake. They need to stay in.
> >
> > C'mon now, re-ording the lines is *certainly* not necessary to work.
>
> That's
On Wed, 28 Jul 1999, Nate Williams wrote:
> >
> > These were changes that were necessary to make ipfw readable enough that
> > I could work with it in this area. They aren't just to clean it up, or
> > just for change's sake. They need to stay in.
>
> C'mon now, re-ording the lines is *certainly
> > > @@ -302,14 +303,15 @@
> > > struct ifnet *rif, struct ifnet *oif)
> > > {
> > > if (ip) {
> > > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct icmp *const icmp
On Tue, 27 Jul 1999, Brian F. Feldman wrote:
> If it will get ALL of you to give it a rest, how about:
> per-rule logging limits
This has been needed for some time now. Also, please don't forget
the oft-repeated request to have seperate accounting and logging counters
so that you ca
On Wed, 28 Jul 1999, Nate Williams wrote:
> > Index: src/sys/netinet/ip_fw.c
> > ===
> > RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> > retrieving revision 1.114
> > diff -u -r1.114 ip_fw.c
> > --- ip_fw.c 1999/06/19 18:43:28
On Tue, Jul 27, 1999 at 10:58:08PM -0700, David O'Brien wrote:
> Lets help these people out. How about adding this to 3.3's RELEASE notes
> and a pointer from our website? (maybe also
> http://www.freebsd.org/handbook/install.html)
If you can give me text, I'll mark it up and add it.
N
--
[i
-hackers,
In the kernel config file you can use symbolic names for the various
COM ports, IO_COM1, IO_COM2, and so on.
These seem be defined in sys/isa/isareg.h.
If you want to configure FreeBSD to boot from a serial console you have
to set BOOT_COMCONSOLE_PORT in /etc/make.conf -- you can't u
-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 you can take a look at come up with
Since you've got it in RCS, you shouldn't have any problem adding new
features. How about a selectable display of fields, and ability to put
them in machine-readable (read: no cut required) form? I'd suggest
having a function that would printf "%s: whatever", arg1 for humans
and "whatever" for mac
> Index: src/sys/netinet/ip_fw.c
> ===
> RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> retrieving revision 1.114
> diff -u -r1.114 ip_fw.c
> --- ip_fw.c 1999/06/19 18:43:28 1.114
> +++ ip_fw.c 1999/07/28 06:29:07
> @@ -106,
I need help finishing it. The ipfw.8 manpage isn't quite fixed yet. When
someone will do that, it will be Ready :) But I've attached it!
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!
I hacked this together last night. The only GNU code I looked at was the
Linux stat(1u) man page. (A man page is forthcoming, especially if there is
some interest in using this implementation.) The code is also available at
http://www.kagekaze.org/stat.c
Regards,
--Keith Stevenson--
--
Keith
On 28 Jul 1999, Dag-Erling Smorgrav wrote:
> "Brian F. Feldman" writes:
> > My point was that it's not a very important thing to do to give out
> > FreeBSD CDs like BSD/OS gives out trial versions of their wares.
>
> Yes, it is. Try doing an FTP install across a 28k8 or 33k6 modem some
> time.
> > > > Implementing it is the easy part, making sure it's the right thing to do
> > > > is the hard part.
> > >
> > > Well, the easy part is done, except for raising limits. Look:
> > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > Implementing it is the easy part, making sure it's the right thing to do
> > > is the hard part.
> >
> > Well, the easy part is done, except for raising limits. Look:
> > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> > ipfw: 1 Deny ICMP:8
On Tue, 27 Jul 1999, Brian F. Feldman wrote:
> If it will get ALL of you to give it a rest, how about:
> per-rule logging limits
This has been needed for some time now. Also, please don't forget
the oft-repeated request to have seperate accounting and logging counters
so that you c
Sheldon Hearn wrote:
> Could someone have a look at the patch proposed on PR 12852? I
> understand the motivation, since it seems reasonable to me that ferror()
> should return EBADF after an attempt to read from stdout. At the moment,
> ferror() returns 0 after an attempt to read from stdout.
I expect that there is a very good reason why this shouldn't be done,
but could it be possible to implement two different algorithms/code
dependant on the size of the file being grepped?
Mark Dickey
m...@bestweb.net
Daniel C. Sobral wrote:
> James Howard wrote:
> >
> > Due to the discussion of sp
On 28 Jul 1999, Dag-Erling Smorgrav wrote:
> "Brian F. Feldman" <[EMAIL PROTECTED]> writes:
> > My point was that it's not a very important thing to do to give out
> > FreeBSD CDs like BSD/OS gives out trial versions of their wares.
>
> Yes, it is. Try doing an FTP install across a 28k8 or 33k6
Sheldon Hearn wrote:
> Could someone have a look at the patch proposed on PR 12852? I
> understand the motivation, since it seems reasonable to me that ferror()
> should return EBADF after an attempt to read from stdout. At the moment,
> ferror() returns 0 after an attempt to read from stdout.
I expect that there is a very good reason why this shouldn't be done,
but could it be possible to implement two different algorithms/code
dependant on the size of the file being grepped?
Mark Dickey
[EMAIL PROTECTED]
Daniel C. Sobral wrote:
> James Howard wrote:
> >
> > Due to the discussion of
1 - 100 of 149 matches
Mail list logo
