Re: devices in sysctl MIB?

[Ben Rosengart]

On Sat, 3 Jul 1999, Chris D. Faulhaber wrote:

> On Sat, 3 Jul 1999, Chris Costello wrote:
> 
> > On Sat, Jul 3, 1999, Marc Nicholas wrote:
> > > I would certainly welcome such info...
> > > 
> > > The info in the /proc filesystem in Linux is certainly nice. (One of the
> > > few things that is!).
> > 
> >Nice, but misplaced.  What does PCI/system version/etc have to
> > do with running processes, exactly?
> > 
> 
> Isn't this what kernfs is for?

Isn't kernfs deprecated in favor of sysctl?

--
 Ben

UNIX Systems Engineer, Skunk Group
StarMedia Network, Inc.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: devices in sysctl MIB?

[Ben Rosengart]

On Sat, 3 Jul 1999, Chris D. Faulhaber wrote:

> On Sat, 3 Jul 1999, Chris Costello wrote:
> 
> > On Sat, Jul 3, 1999, Marc Nicholas wrote:
> > > I would certainly welcome such info...
> > > 
> > > The info in the /proc filesystem in Linux is certainly nice. (One of the
> > > few things that is!).
> > 
> >Nice, but misplaced.  What does PCI/system version/etc have to
> > do with running processes, exactly?
> > 
> 
> Isn't this what kernfs is for?

Isn't kernfs deprecated in favor of sysctl?

--
 Ben

UNIX Systems Engineer, Skunk Group
StarMedia Network, Inc.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to start to be a hacker?

[G. Adam Stanislav]

On Sat, Jul 03, 1999 at 06:11:08PM -0600, Wes Peters wrote:
> Trust me, greenie, those of us who a FAR from 16 wish we weren't.  ;^)

What, and miss the sixties??? Get back to your handbasket! :-)

Adam


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to start to be a hacker?

[G. Adam Stanislav]

On Sat, Jul 03, 1999 at 06:11:08PM -0600, Wes Peters wrote:
> Trust me, greenie, those of us who a FAR from 16 wish we weren't.  ;^)

What, and miss the sixties??? Get back to your handbasket! :-)

Adam


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Greg Lehey]

On Saturday,  3 July 1999 at 23:31:20 -0500, Jonathan Lemon wrote:
> On Jul 07, 1999 at 01:51:28PM +0930, Greg Lehey wrote:
>> On Saturday,  3 July 1999 at 23:10:29 -0500, Jonathan Lemon wrote:
>>> On Jul 07, 1999 at 12:04:35PM +0800, Peter Wemm wrote:
 Is there interest in doing something like this in general?
>>>
>>> YES!  As a matter of fact, I've done something similar to this already,
>>> but instead of a queue, it's a variant of poll which passes in and out
>>> "change lists"; a list of fd's which have had status changes since the
>>> last call.  I've been trying to bring it up for discussion on the -arch
>>> list, but it's been dead.  (I think it was just fixed recently).
>>
>> Did you see the presentation "A scalable and explicit event delivery
>> mechanism for UNIX" at USENIX?  It sounded quite interesting.  Page
>> 253 of the proceedings.
>
> Is this the paper by Mogul, et al?

Yes, this is the one.

> I didn't make it to USENIX, and don't have the proceedings at hand,
> but my implementation is fairly similar to a series of papers that
> Jeff Mogul has produced regarding web scalability.

Good.  I thought the paper (presented by Gaurav Banga) was quite
interesting, but I wasn't convinced it was the only way to do it.
Unfortunately, I haven't found time to look at it in more detail.

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Greg Lehey]

On Saturday,  3 July 1999 at 23:31:20 -0500, Jonathan Lemon wrote:
> On Jul 07, 1999 at 01:51:28PM +0930, Greg Lehey wrote:
>> On Saturday,  3 July 1999 at 23:10:29 -0500, Jonathan Lemon wrote:
>>> On Jul 07, 1999 at 12:04:35PM +0800, Peter Wemm wrote:
 Is there interest in doing something like this in general?
>>>
>>> YES!  As a matter of fact, I've done something similar to this already,
>>> but instead of a queue, it's a variant of poll which passes in and out
>>> "change lists"; a list of fd's which have had status changes since the
>>> last call.  I've been trying to bring it up for discussion on the -arch
>>> list, but it's been dead.  (I think it was just fixed recently).
>>
>> Did you see the presentation "A scalable and explicit event delivery
>> mechanism for UNIX" at USENIX?  It sounded quite interesting.  Page
>> 253 of the proceedings.
>
> Is this the paper by Mogul, et al?

Yes, this is the one.

> I didn't make it to USENIX, and don't have the proceedings at hand,
> but my implementation is fairly similar to a series of papers that
> Jeff Mogul has produced regarding web scalability.

Good.  I thought the paper (presented by Gaurav Banga) was quite
interesting, but I wasn't convinced it was the only way to do it.
Unfortunately, I haven't found time to look at it in more detail.

Greg
--
See complete headers for address, home page and phone numbers
finger g...@lemis.com for PGP public key


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Brian F. Feldman]

On Sun, 4 Jul 1999, Peter Wemm wrote:

> "Brian F. Feldman" wrote:
> > On Fri, 2 Jul 1999, Jonathan Lemon wrote:
> > 
> > > In article  [EMAIL PROTECTED]> you write:
> > > >now supports the select() and poll() system calls.  My question is really 
> one
> > > >of usage.  Why would one us poll() over select()?  Is select eventually go
> ing
> > > >to go away for some reason?  
> > > 
> > > select() as a user-level call will never go away; there is a large base
> > > of code that uses it.
> > > 
> > > poll() is faster (it doesn't have to do bit twiddling), and it's interface
> > > is cleaner (it can report invalid fd's, something select() can't do).  As
> > > its functionality is a superset of select()'s, it is used as the internal
> > > implementation for select().
> > 
> > Actually, select() doesn't require horrendous amounts of copyin()s, which
> > poll() does. So have you benchmarked the two? I'd expect select to be faster.
> 
> Actually.. select() has three copyins and three copyouts per call.  poll()
> has one copyin and one copyout per call.
> 

But poll() copies in HUGE amounts of data compared to the few bytes for
thousands of FDs that select does.

> Now what I particular like is the event queue system that David Filo put
> together for Yahoo. In a nutshell you create a queue (a fd), and then
> register the descriptors you want to monitor with the queue.  You then run
> an accept()-like loop where the accept returns the fd number that has met
> the conditions you asked for.  For example, if you wanted to know if fd
> number 4251 becomes readable, then the accept would return 4251. This has
> potential to work across multiple processes sharing a queue so that events
> could get round robined or whatever.  The other good part is that it
> maintains the state and lists persistantly and doesn't have to keep copying
> it to/from the kernel.  It handles 50,000 to 100,000 connections without
> too much trouble.  You can still use this with select as the queue fd
> becomes readable when there is an event waiting for your process.
> 
> Is there interest in doing something like this in general?

Yes! That would not replace select() or poll(), but it would be awesome
to have!

> 
> Cheers,
> -Peter
> --
> Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Brian F. Feldman]

On Sun, 4 Jul 1999, Peter Wemm wrote:

> "Brian F. Feldman" wrote:
> > On Fri, 2 Jul 1999, Jonathan Lemon wrote:
> > 
> > > In article 
> > >  0...@crb.crb-web.com> you write:
> > > >now supports the select() and poll() system calls.  My question is 
> > > >really 
> one
> > > >of usage.  Why would one us poll() over select()?  Is select eventually 
> > > >go
> ing
> > > >to go away for some reason?  
> > > 
> > > select() as a user-level call will never go away; there is a large base
> > > of code that uses it.
> > > 
> > > poll() is faster (it doesn't have to do bit twiddling), and it's interface
> > > is cleaner (it can report invalid fd's, something select() can't do).  As
> > > its functionality is a superset of select()'s, it is used as the internal
> > > implementation for select().
> > 
> > Actually, select() doesn't require horrendous amounts of copyin()s, which
> > poll() does. So have you benchmarked the two? I'd expect select to be 
> > faster.
> 
> Actually.. select() has three copyins and three copyouts per call.  poll()
> has one copyin and one copyout per call.
> 

But poll() copies in HUGE amounts of data compared to the few bytes for
thousands of FDs that select does.

> Now what I particular like is the event queue system that David Filo put
> together for Yahoo. In a nutshell you create a queue (a fd), and then
> register the descriptors you want to monitor with the queue.  You then run
> an accept()-like loop where the accept returns the fd number that has met
> the conditions you asked for.  For example, if you wanted to know if fd
> number 4251 becomes readable, then the accept would return 4251. This has
> potential to work across multiple processes sharing a queue so that events
> could get round robined or whatever.  The other good part is that it
> maintains the state and lists persistantly and doesn't have to keep copying
> it to/from the kernel.  It handles 50,000 to 100,000 connections without
> too much trouble.  You can still use this with select as the queue fd
> becomes readable when there is an event waiting for your process.
> 
> Is there interest in doing something like this in general?

Yes! That would not replace select() or poll(), but it would be awesome
to have!

> 
> Cheers,
> -Peter
> --
> Peter Wemm - pe...@freebsd.org; pe...@yahoo-inc.com; pe...@netplex.com.au
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

login problem:

[Gustavo V G C Rios]

My login.conf classes does not work, i have already looked for into The
Complete FBSD, man pages, /usr/src/lib/libutil/* but nothing works the
way i wanna.
i think that only you hackers can help me.
Here goes the classes: 


shelldef:\
:cputime=10m:\
:filesize=unlimited:\
:datasize=3m:\
:stacksize=2m:\ 
:coredumpsize=unlimited:\
:memoryuse=3m:\
:memorylocked=1m:\
:openfiles=15:\
:umask=027:\ 
:idletime=1m:\
:accounted=true:\
:minpasswordlen=10:\
:tc=auth-defaults:

shell:\
:maxproc=10:\
:tc=shelldef:


I have a user that belong to shell shell login classes, but he is not
disconnected after 1 minute of idle time?
What is going? I don't really have any ideia about it!
Maybe my mistaken is too stupid, but..


Thank you for your time and cooperation.

-- 
What about something different this year:
Crash your FreeBSD box!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

login problem:

[Gustavo V G C Rios]

My login.conf classes does not work, i have already looked for into The
Complete FBSD, man pages, /usr/src/lib/libutil/* but nothing works the
way i wanna.
i think that only you hackers can help me.
Here goes the classes: 


shelldef:\
:cputime=10m:\
:filesize=unlimited:\
:datasize=3m:\
:stacksize=2m:\ 
:coredumpsize=unlimited:\
:memoryuse=3m:\
:memorylocked=1m:\
:openfiles=15:\
:umask=027:\ 
:idletime=1m:\
:accounted=true:\
:minpasswordlen=10:\
:tc=auth-defaults:

shell:\
:maxproc=10:\
:tc=shelldef:


I have a user that belong to shell shell login classes, but he is not
disconnected after 1 minute of idle time?
What is going? I don't really have any ideia about it!
Maybe my mistaken is too stupid, but..


Thank you for your time and cooperation.

-- 
What about something different this year:
Crash your FreeBSD box!


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

poll() scalability

[Jonathan Lemon]

This is an earlier posting that I attempted to make, perhaps
it can provide a starting point for discussion.  While this 
is already implemented, I'm not adverse to tossing it all for
something better.
--
Jonathan


- Forwarded message from [EMAIL PROTECTED] -

Date: Mon, 5 Apr 1999 17:42:02 -0500
From: Jonathan Lemon <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]

I'd like to open discussion on adding a new interface to FreeBSD,
specifically, a variant of poll().

The problem is that poll() (and select(), as well) do not scale
well as the number of open file descriptors increases.  When there
are a large number of descriptors under consideration, poll() takes
an inordinate amount of time.  For the purposes of my particular 
application, "large" translates into roughly 40K descriptors.

As having to walk this descriptor list (and pass it between user and
kernel space) is unpalatable, I would like to have the interface
simply take a "change" list instead.  The kernel would keep the 
state of the descriptors being examined, and would in turn, return
a short list of descriptors that actually had any activity.

In essence, I want to move the large "struct pollfd" array that I 
have into the kernel, and then instruct the kernel to add/remove
entries from this array, and only return the array subset which
has activity.

A possible (actually, my current) implementation looks like this:

struct fd_change {
short   fd;
short   events; 
}; 

int
new_poll(
int nchanges;   // entries in new changelist
struct fd_change *changelist;   // changes to be made
int n_events;   // max size of output list
struct fd_change *event;// returned list of events
int timeout;// timeout (same as poll)
)

Where the returned value is either an error, or the number of events
stored in the returned changelist.

Some pseudo-code that would exercise the interface:

struct fd_change fc[ MAXCHANGE ];

fc[0].fd = 20;
fc[0].events = ADD | READ ; // add, mark read "interest"

fc[1].fd = -1;  // ignore this one

fc[2].fd = 32;
fc[2].events = DELETE ; // delete previous fd

fc[3].fd = 46;
fc[3].events = WRITE ;  // ask for writable events

n_changes = new_poll(4, fc, MAXCHANGE, fc, -1);


Comments?  Note that I haven't discussed the implementation details;
the implementation is done, and can probably be altered/improved, 
but I would like to solicit feedback on the feasability of the interface.
--
Jonathan

- End forwarded message -


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

poll() scalability

[Jonathan Lemon]

This is an earlier posting that I attempted to make, perhaps
it can provide a starting point for discussion.  While this 
is already implemented, I'm not adverse to tossing it all for
something better.
--
Jonathan


- Forwarded message from owner-freebsd-a...@freebsd.org -

Date: Mon, 5 Apr 1999 17:42:02 -0500
From: Jonathan Lemon 
To: freebsd-a...@freebsd.org

I'd like to open discussion on adding a new interface to FreeBSD,
specifically, a variant of poll().

The problem is that poll() (and select(), as well) do not scale
well as the number of open file descriptors increases.  When there
are a large number of descriptors under consideration, poll() takes
an inordinate amount of time.  For the purposes of my particular 
application, "large" translates into roughly 40K descriptors.

As having to walk this descriptor list (and pass it between user and
kernel space) is unpalatable, I would like to have the interface
simply take a "change" list instead.  The kernel would keep the 
state of the descriptors being examined, and would in turn, return
a short list of descriptors that actually had any activity.

In essence, I want to move the large "struct pollfd" array that I 
have into the kernel, and then instruct the kernel to add/remove
entries from this array, and only return the array subset which
has activity.

A possible (actually, my current) implementation looks like this:

struct fd_change {
short   fd;
short   events; 
}; 

int
new_poll(
int nchanges;   // entries in new changelist
struct fd_change *changelist;   // changes to be made
int n_events;   // max size of output list
struct fd_change *event;// returned list of events
int timeout;// timeout (same as poll)
)

Where the returned value is either an error, or the number of events
stored in the returned changelist.

Some pseudo-code that would exercise the interface:

struct fd_change fc[ MAXCHANGE ];

fc[0].fd = 20;
fc[0].events = ADD | READ ; // add, mark read "interest"

fc[1].fd = -1;  // ignore this one

fc[2].fd = 32;
fc[2].events = DELETE ; // delete previous fd

fc[3].fd = 46;
fc[3].events = WRITE ;  // ask for writable events

n_changes = new_poll(4, fc, MAXCHANGE, fc, -1);


Comments?  Note that I haven't discussed the implementation details;
the implementation is done, and can probably be altered/improved, 
but I would like to solicit feedback on the feasability of the interface.
--
Jonathan

- End forwarded message -


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Jonathan Lemon]

On Jul 07, 1999 at 01:51:28PM +0930, Greg Lehey wrote:
> On Saturday,  3 July 1999 at 23:10:29 -0500, Jonathan Lemon wrote:
> > On Jul 07, 1999 at 12:04:35PM +0800, Peter Wemm wrote:
> >> Is there interest in doing something like this in general?
> >
> > YES!  As a matter of fact, I've done something similar to this already,
> > but instead of a queue, it's a variant of poll which passes in and out
> > "change lists"; a list of fd's which have had status changes since the
> > last call.  I've been trying to bring it up for discussion on the -arch
> > list, but it's been dead.  (I think it was just fixed recently).
> 
> Did you see the presentation "A scalable and explicit event delivery
> mechanism for UNIX" at USENIX?  It sounded quite interesting.  Page
> 253 of the proceedings.

Is this the paper by Mogul, et al?  I didn't make it to USENIX, and
don't have the proceedings at hand, but my implementation is fairly
similar to a series of papers that Jeff Mogul has produced regarding
web scalability.
--
Jonathan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Jonathan Lemon]

On Jul 07, 1999 at 01:51:28PM +0930, Greg Lehey wrote:
> On Saturday,  3 July 1999 at 23:10:29 -0500, Jonathan Lemon wrote:
> > On Jul 07, 1999 at 12:04:35PM +0800, Peter Wemm wrote:
> >> Is there interest in doing something like this in general?
> >
> > YES!  As a matter of fact, I've done something similar to this already,
> > but instead of a queue, it's a variant of poll which passes in and out
> > "change lists"; a list of fd's which have had status changes since the
> > last call.  I've been trying to bring it up for discussion on the -arch
> > list, but it's been dead.  (I think it was just fixed recently).
> 
> Did you see the presentation "A scalable and explicit event delivery
> mechanism for UNIX" at USENIX?  It sounded quite interesting.  Page
> 253 of the proceedings.

Is this the paper by Mogul, et al?  I didn't make it to USENIX, and
don't have the proceedings at hand, but my implementation is fairly
similar to a series of papers that Jeff Mogul has produced regarding
web scalability.
--
Jonathan


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Greg Lehey]

On Saturday,  3 July 1999 at 23:10:29 -0500, Jonathan Lemon wrote:
> On Jul 07, 1999 at 12:04:35PM +0800, Peter Wemm wrote:
>> "Brian F. Feldman" wrote:
>>> On Fri, 2 Jul 1999, Jonathan Lemon wrote:
>>>
 In article > [EMAIL PROTECTED]> you write:
> now supports the select() and poll() system calls.  My question is really
>> one
> of usage.  Why would one us poll() over select()?  Is select eventually go
>> ing
> to go away for some reason?

 select() as a user-level call will never go away; there is a large base
 of code that uses it.

 poll() is faster (it doesn't have to do bit twiddling), and it's interface
 is cleaner (it can report invalid fd's, something select() can't do).  As
 its functionality is a superset of select()'s, it is used as the internal
 implementation for select().
>>>
>>> Actually, select() doesn't require horrendous amounts of copyin()s, which
>>> poll() does. So have you benchmarked the two? I'd expect select to be faster.
>>
>> Actually.. select() has three copyins and three copyouts per call.  poll()
>> has one copyin and one copyout per call.
>>
>> Now what I particular like is the event queue system that David Filo put
>> together for Yahoo. In a nutshell you create a queue (a fd), and then
>> register the descriptors you want to monitor with the queue.  You then run
>> an accept()-like loop where the accept returns the fd number that has met
>> the conditions you asked for.  For example, if you wanted to know if fd
>> number 4251 becomes readable, then the accept would return 4251. This has
>> potential to work across multiple processes sharing a queue so that events
>> could get round robined or whatever.  The other good part is that it
>> maintains the state and lists persistantly and doesn't have to keep copying
>> it to/from the kernel.  It handles 50,000 to 100,000 connections without
>> too much trouble.  You can still use this with select as the queue fd
>> becomes readable when there is an event waiting for your process.

This sounds rather like what Tandem did in its
TOS^H^H^HGuardian^H^H^H^H^H^H^H^HNonStop Kernel operating system.  At
the user level, you had the choice of calling awaitio (-1), which
would return the next completion on any fd, or awaitio (4251), which
would return information on that specific fd.  And of course you have
the choice of blocking or not if the conditions aren't met.  Of
course, the performance implications of waiting on a specific fd are
another issue.

>> Is there interest in doing something like this in general?
>
> YES!  As a matter of fact, I've done something similar to this already,
> but instead of a queue, it's a variant of poll which passes in and out
> "change lists"; a list of fd's which have had status changes since the
> last call.  I've been trying to bring it up for discussion on the -arch
> list, but it's been dead.  (I think it was just fixed recently).

Did you see the presentation "A scalable and explicit event delivery
mechanism for UNIX" at USENIX?  It sounded quite interesting.  Page
253 of the proceedings.

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Greg Lehey]

On Saturday,  3 July 1999 at 23:10:29 -0500, Jonathan Lemon wrote:
> On Jul 07, 1999 at 12:04:35PM +0800, Peter Wemm wrote:
>> "Brian F. Feldman" wrote:
>>> On Fri, 2 Jul 1999, Jonathan Lemon wrote:
>>>
 In article > 0...@crb.crb-web.com> you write:
> now supports the select() and poll() system calls.  My question is really
>> one
> of usage.  Why would one us poll() over select()?  Is select eventually go
>> ing
> to go away for some reason?

 select() as a user-level call will never go away; there is a large base
 of code that uses it.

 poll() is faster (it doesn't have to do bit twiddling), and it's interface
 is cleaner (it can report invalid fd's, something select() can't do).  As
 its functionality is a superset of select()'s, it is used as the internal
 implementation for select().
>>>
>>> Actually, select() doesn't require horrendous amounts of copyin()s, which
>>> poll() does. So have you benchmarked the two? I'd expect select to be 
>>> faster.
>>
>> Actually.. select() has three copyins and three copyouts per call.  poll()
>> has one copyin and one copyout per call.
>>
>> Now what I particular like is the event queue system that David Filo put
>> together for Yahoo. In a nutshell you create a queue (a fd), and then
>> register the descriptors you want to monitor with the queue.  You then run
>> an accept()-like loop where the accept returns the fd number that has met
>> the conditions you asked for.  For example, if you wanted to know if fd
>> number 4251 becomes readable, then the accept would return 4251. This has
>> potential to work across multiple processes sharing a queue so that events
>> could get round robined or whatever.  The other good part is that it
>> maintains the state and lists persistantly and doesn't have to keep copying
>> it to/from the kernel.  It handles 50,000 to 100,000 connections without
>> too much trouble.  You can still use this with select as the queue fd
>> becomes readable when there is an event waiting for your process.

This sounds rather like what Tandem did in its
TOS^H^H^HGuardian^H^H^H^H^H^H^H^HNonStop Kernel operating system.  At
the user level, you had the choice of calling awaitio (-1), which
would return the next completion on any fd, or awaitio (4251), which
would return information on that specific fd.  And of course you have
the choice of blocking or not if the conditions aren't met.  Of
course, the performance implications of waiting on a specific fd are
another issue.

>> Is there interest in doing something like this in general?
>
> YES!  As a matter of fact, I've done something similar to this already,
> but instead of a queue, it's a variant of poll which passes in and out
> "change lists"; a list of fd's which have had status changes since the
> last call.  I've been trying to bring it up for discussion on the -arch
> list, but it's been dead.  (I think it was just fixed recently).

Did you see the presentation "A scalable and explicit event delivery
mechanism for UNIX" at USENIX?  It sounded quite interesting.  Page
253 of the proceedings.

Greg
--
See complete headers for address, home page and phone numbers
finger g...@lemis.com for PGP public key


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Jonathan Lemon]

On Jul 07, 1999 at 12:04:35PM +0800, Peter Wemm wrote:
> "Brian F. Feldman" wrote:
> > On Fri, 2 Jul 1999, Jonathan Lemon wrote:
> > 
> > > In article  [EMAIL PROTECTED]> you write:
> > > >now supports the select() and poll() system calls.  My question is really 
> one
> > > >of usage.  Why would one us poll() over select()?  Is select eventually go
> ing
> > > >to go away for some reason?  
> > > 
> > > select() as a user-level call will never go away; there is a large base
> > > of code that uses it.
> > > 
> > > poll() is faster (it doesn't have to do bit twiddling), and it's interface
> > > is cleaner (it can report invalid fd's, something select() can't do).  As
> > > its functionality is a superset of select()'s, it is used as the internal
> > > implementation for select().
> > 
> > Actually, select() doesn't require horrendous amounts of copyin()s, which
> > poll() does. So have you benchmarked the two? I'd expect select to be faster.
> 
> Actually.. select() has three copyins and three copyouts per call.  poll()
> has one copyin and one copyout per call.
> 
> Now what I particular like is the event queue system that David Filo put
> together for Yahoo. In a nutshell you create a queue (a fd), and then
> register the descriptors you want to monitor with the queue.  You then run
> an accept()-like loop where the accept returns the fd number that has met
> the conditions you asked for.  For example, if you wanted to know if fd
> number 4251 becomes readable, then the accept would return 4251. This has
> potential to work across multiple processes sharing a queue so that events
> could get round robined or whatever.  The other good part is that it
> maintains the state and lists persistantly and doesn't have to keep copying
> it to/from the kernel.  It handles 50,000 to 100,000 connections without
> too much trouble.  You can still use this with select as the queue fd
> becomes readable when there is an event waiting for your process.
> 
> Is there interest in doing something like this in general?

YES!  As a matter of fact, I've done something similar to this already,
but instead of a queue, it's a variant of poll which passes in and out
"change lists"; a list of fd's which have had status changes since the
last call.  I've been trying to bring it up for discussion on the -arch
list, but it's been dead.  (I think it was just fixed recently).
--
Jonathan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Jonathan Lemon]

On Jul 07, 1999 at 12:04:35PM +0800, Peter Wemm wrote:
> "Brian F. Feldman" wrote:
> > On Fri, 2 Jul 1999, Jonathan Lemon wrote:
> > 
> > > In article 
> > >  0...@crb.crb-web.com> you write:
> > > >now supports the select() and poll() system calls.  My question is 
> > > >really 
> one
> > > >of usage.  Why would one us poll() over select()?  Is select eventually 
> > > >go
> ing
> > > >to go away for some reason?  
> > > 
> > > select() as a user-level call will never go away; there is a large base
> > > of code that uses it.
> > > 
> > > poll() is faster (it doesn't have to do bit twiddling), and it's interface
> > > is cleaner (it can report invalid fd's, something select() can't do).  As
> > > its functionality is a superset of select()'s, it is used as the internal
> > > implementation for select().
> > 
> > Actually, select() doesn't require horrendous amounts of copyin()s, which
> > poll() does. So have you benchmarked the two? I'd expect select to be 
> > faster.
> 
> Actually.. select() has three copyins and three copyouts per call.  poll()
> has one copyin and one copyout per call.
> 
> Now what I particular like is the event queue system that David Filo put
> together for Yahoo. In a nutshell you create a queue (a fd), and then
> register the descriptors you want to monitor with the queue.  You then run
> an accept()-like loop where the accept returns the fd number that has met
> the conditions you asked for.  For example, if you wanted to know if fd
> number 4251 becomes readable, then the accept would return 4251. This has
> potential to work across multiple processes sharing a queue so that events
> could get round robined or whatever.  The other good part is that it
> maintains the state and lists persistantly and doesn't have to keep copying
> it to/from the kernel.  It handles 50,000 to 100,000 connections without
> too much trouble.  You can still use this with select as the queue fd
> becomes readable when there is an event waiting for your process.
> 
> Is there interest in doing something like this in general?

YES!  As a matter of fact, I've done something similar to this already,
but instead of a queue, it's a variant of poll which passes in and out
"change lists"; a list of fd's which have had status changes since the
last call.  I've been trying to bring it up for discussion on the -arch
list, but it's been dead.  (I think it was just fixed recently).
--
Jonathan


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Peter Wemm]

"Brian F. Feldman" wrote:
> On Fri, 2 Jul 1999, Jonathan Lemon wrote:
> 
> > In article  you write:
> > >now supports the select() and poll() system calls.  My question is really 
one
> > >of usage.  Why would one us poll() over select()?  Is select eventually go
ing
> > >to go away for some reason?  
> > 
> > select() as a user-level call will never go away; there is a large base
> > of code that uses it.
> > 
> > poll() is faster (it doesn't have to do bit twiddling), and it's interface
> > is cleaner (it can report invalid fd's, something select() can't do).  As
> > its functionality is a superset of select()'s, it is used as the internal
> > implementation for select().
> 
> Actually, select() doesn't require horrendous amounts of copyin()s, which
> poll() does. So have you benchmarked the two? I'd expect select to be faster.

Actually.. select() has three copyins and three copyouts per call.  poll()
has one copyin and one copyout per call.

Now what I particular like is the event queue system that David Filo put
together for Yahoo. In a nutshell you create a queue (a fd), and then
register the descriptors you want to monitor with the queue.  You then run
an accept()-like loop where the accept returns the fd number that has met
the conditions you asked for.  For example, if you wanted to know if fd
number 4251 becomes readable, then the accept would return 4251. This has
potential to work across multiple processes sharing a queue so that events
could get round robined or whatever.  The other good part is that it
maintains the state and lists persistantly and doesn't have to keep copying
it to/from the kernel.  It handles 50,000 to 100,000 connections without
too much trouble.  You can still use this with select as the queue fd
becomes readable when there is an event waiting for your process.

Is there interest in doing something like this in general?

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: support for i386 hardware debug watch points

[Greg Lehey]

On Saturday,  3 July 1999 at 12:13:55 -0400, Brian F. Feldman wrote:
> On Sat, 3 Jul 1999, Peter Wemm wrote:
>
>> Thomas David Rivers wrote:

 Is there any interest in supporting something like this in FreeBSD?
 I'm volunteering to spend some cycles on this, but I don't want to go
 to the effort if there's little chance that the work would be
 integrated.
>>>
>>>Scan through the mail archives - I brought this up about this
>>>  time last year, I think...
>>>
>>>There were several responses - some people may be willing to
>>>  assist...
>>
>> I'll chime in..  I'd be quite willing to bring something like this in,
>> assuming it was done reasonably cleanly.  It shouldn't be too hard to do it
>> without imparing portability across cpu/arch types.
>>
>> I think this would be quite useful, especially if gdb could be made aware
>> of it too.
>
> I think this would be great too, but I have a concern. Not all CPUs (x86)
> support this; make ABSOLUTELY sure it doesn't do this kind of thing on
> hardware which doesn't support it, please!

I have code which does this, in a debugger which also offers some
features which ddb doesn't have.  Unfortunately, I trusted it to DDS
tapes, with the result that I can't read the latest version.  I've
retrieved a version on ftp://ftp.lemis.com/pub/lowbug.tar.gz, but it's
out of date in some respects.  Still, it might be of use as a basis
for new work.

I note that the documentation includes a copy of the GPL.  I can't
recall why; I never placed the debugger under the GPL.

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Peter Wemm]

"Brian F. Feldman" wrote:
> On Fri, 2 Jul 1999, Jonathan Lemon wrote:
> 
> > In article  you write:
> > >now supports the select() and poll() system calls.  My question is really 
one
> > >of usage.  Why would one us poll() over select()?  Is select eventually go
ing
> > >to go away for some reason?  
> > 
> > select() as a user-level call will never go away; there is a large base
> > of code that uses it.
> > 
> > poll() is faster (it doesn't have to do bit twiddling), and it's interface
> > is cleaner (it can report invalid fd's, something select() can't do).  As
> > its functionality is a superset of select()'s, it is used as the internal
> > implementation for select().
> 
> Actually, select() doesn't require horrendous amounts of copyin()s, which
> poll() does. So have you benchmarked the two? I'd expect select to be faster.

Actually.. select() has three copyins and three copyouts per call.  poll()
has one copyin and one copyout per call.

Now what I particular like is the event queue system that David Filo put
together for Yahoo. In a nutshell you create a queue (a fd), and then
register the descriptors you want to monitor with the queue.  You then run
an accept()-like loop where the accept returns the fd number that has met
the conditions you asked for.  For example, if you wanted to know if fd
number 4251 becomes readable, then the accept would return 4251. This has
potential to work across multiple processes sharing a queue so that events
could get round robined or whatever.  The other good part is that it
maintains the state and lists persistantly and doesn't have to keep copying
it to/from the kernel.  It handles 50,000 to 100,000 connections without
too much trouble.  You can still use this with select as the queue fd
becomes readable when there is an event waiting for your process.

Is there interest in doing something like this in general?

Cheers,
-Peter
--
Peter Wemm - pe...@freebsd.org; pe...@yahoo-inc.com; pe...@netplex.com.au



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: support for i386 hardware debug watch points

[Greg Lehey]

On Saturday,  3 July 1999 at 12:13:55 -0400, Brian F. Feldman wrote:
> On Sat, 3 Jul 1999, Peter Wemm wrote:
>
>> Thomas David Rivers wrote:

 Is there any interest in supporting something like this in FreeBSD?
 I'm volunteering to spend some cycles on this, but I don't want to go
 to the effort if there's little chance that the work would be
 integrated.
>>>
>>>Scan through the mail archives - I brought this up about this
>>>  time last year, I think...
>>>
>>>There were several responses - some people may be willing to
>>>  assist...
>>
>> I'll chime in..  I'd be quite willing to bring something like this in,
>> assuming it was done reasonably cleanly.  It shouldn't be too hard to do it
>> without imparing portability across cpu/arch types.
>>
>> I think this would be quite useful, especially if gdb could be made aware
>> of it too.
>
> I think this would be great too, but I have a concern. Not all CPUs (x86)
> support this; make ABSOLUTELY sure it doesn't do this kind of thing on
> hardware which doesn't support it, please!

I have code which does this, in a debugger which also offers some
features which ddb doesn't have.  Unfortunately, I trusted it to DDS
tapes, with the result that I can't read the latest version.  I've
retrieved a version on ftp://ftp.lemis.com/pub/lowbug.tar.gz, but it's
out of date in some respects.  Still, it might be of use as a basis
for new work.

I note that the documentation includes a copy of the GPL.  I can't
recall why; I never placed the debugger under the GPL.

Greg
--
See complete headers for address, home page and phone numbers
finger g...@lemis.com for PGP public key


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: devices in sysctl MIB?

[Chris D. Faulhaber]

On Sat, 3 Jul 1999, Chris Costello wrote:

> On Sat, Jul 3, 1999, Marc Nicholas wrote:
> > I would certainly welcome such info...
> > 
> > The info in the /proc filesystem in Linux is certainly nice. (One of the
> > few things that is!).
> 
>Nice, but misplaced.  What does PCI/system version/etc have to
> do with running processes, exactly?
> 

Isn't this what kernfs is for?

DESCRIPTION
 The kernel file system, or kernfs, provides access to information on
the currently running kernel...
 

-
Chris D. Faulhaber <[EMAIL PROTECTED]>  |  All the true gurus I've met never
System/Network Administrator,|  claimed they were one, and always
Reality Check Information, Inc.  |  pointed to someone better.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Do we need GNU readline ??

[Pedro F. Giffuni]

I was building a library covered by the LGPL when I found this jewel
under readline/README:
_
This is a line-editing library.  It can be linked into almost any
program to provide command-line editing and recall.

It is call-compatible with the FSF readline library, but it is a
fraction of the size (and offers fewer features).  It does not use
standard I/O.  It is distributed under a "C News-like" copyright.
...
An earlier version was distributed with Byron's rc.  Principal
changes over that version include:
Faster.
Is eight-bit clean (thanks to [EMAIL PROTECTED])
Written in K&R C, but ANSI compliant (gcc all warnings)
Propagates EOF properly; rc trip test now passes
Doesn't need or use or provide memmove.
More robust
Calling sequence changed to be compatible with readline.
Test program, new manpage, better configuration
More system-independant; includes Unix and OS-9 support.

Enjoy,
Rich $alz
<[EMAIL PROTECTED]>

 Copyright 1992 Simmule Turner and Rich Salz.  All rights reserved.

 This software is not subject to any license of the American Telephone
 and Telegraph Company or of the Regents of the University of
California.
 Permission is granted to anyone to use this software for any purpose on
 any computer system, and to alter it and redistribute it freely,
subject
 to the following restrictions:
 1. The authors are not responsible for the consequences of use of this
software, no matter how awful, even if they arise from flaws in it.
 2. The origin of this software must not be misrepresented, either by
explicit claim or by omission.  Since few users ever read sources,
credits must appear in the documentation.
 3. Altered versions must be plainly marked as such, and must not be
misrepresented as being the original software.  Since few users
ever read sources, credits must appear in the documentation.
 4. This notice may not be removed or altered.


OTOH, from our "man readline":
...
COPYRIGHT
   Readline  is Copyright (C) 1989, 1991, 1993, 1995, 1996 by
   the Free Software Foundation, Inc.
...
BUGS
   It's too big and too slow.
_

So the question is: Do we really need the complete, bigger GPL'd version
or would it be good if I look for the older, smaller, but free version?

cheers,
Pedro.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: devices in sysctl MIB?

[Chris D. Faulhaber]

On Sat, 3 Jul 1999, Chris Costello wrote:

> On Sat, Jul 3, 1999, Marc Nicholas wrote:
> > I would certainly welcome such info...
> > 
> > The info in the /proc filesystem in Linux is certainly nice. (One of the
> > few things that is!).
> 
>Nice, but misplaced.  What does PCI/system version/etc have to
> do with running processes, exactly?
> 

Isn't this what kernfs is for?

DESCRIPTION
 The kernel file system, or kernfs, provides access to information on
the currently running kernel...
 

-
Chris D. Faulhaber   |  All the true gurus I've met never
System/Network Administrator,|  claimed they were one, and always
Reality Check Information, Inc.  |  pointed to someone better.




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Do we need GNU readline ??

[Pedro F. Giffuni]

I was building a library covered by the LGPL when I found this jewel
under readline/README:
_
This is a line-editing library.  It can be linked into almost any
program to provide command-line editing and recall.

It is call-compatible with the FSF readline library, but it is a
fraction of the size (and offers fewer features).  It does not use
standard I/O.  It is distributed under a "C News-like" copyright.
...
An earlier version was distributed with Byron's rc.  Principal
changes over that version include:
Faster.
Is eight-bit clean (thanks to bren...@cs.widener.edu)
Written in K&R C, but ANSI compliant (gcc all warnings)
Propagates EOF properly; rc trip test now passes
Doesn't need or use or provide memmove.
More robust
Calling sequence changed to be compatible with readline.
Test program, new manpage, better configuration
More system-independant; includes Unix and OS-9 support.

Enjoy,
Rich $alz


 Copyright 1992 Simmule Turner and Rich Salz.  All rights reserved.

 This software is not subject to any license of the American Telephone
 and Telegraph Company or of the Regents of the University of
California.
 Permission is granted to anyone to use this software for any purpose on
 any computer system, and to alter it and redistribute it freely,
subject
 to the following restrictions:
 1. The authors are not responsible for the consequences of use of this
software, no matter how awful, even if they arise from flaws in it.
 2. The origin of this software must not be misrepresented, either by
explicit claim or by omission.  Since few users ever read sources,
credits must appear in the documentation.
 3. Altered versions must be plainly marked as such, and must not be
misrepresented as being the original software.  Since few users
ever read sources, credits must appear in the documentation.
 4. This notice may not be removed or altered.


OTOH, from our "man readline":
...
COPYRIGHT
   Readline  is Copyright (C) 1989, 1991, 1993, 1995, 1996 by
   the Free Software Foundation, Inc.
...
BUGS
   It's too big and too slow.
_

So the question is: Do we really need the complete, bigger GPL'd version
or would it be good if I look for the older, smaller, but free version?

cheers,
Pedro.




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: devices in sysctl MIB?

[Chris Costello]

On Sat, Jul 3, 1999, Marc Nicholas wrote:
> I would certainly welcome such info...
> 
> The info in the /proc filesystem in Linux is certainly nice. (One of the
> few things that is!).

   Nice, but misplaced.  What does PCI/system version/etc have to
do with running processes, exactly?

> -marc

-- 
Chris Costello<[EMAIL PROTECTED]>
Backups?  We doan *NEED* no steenking baX%^~,VbKxNO CARRIER


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: devices in sysctl MIB?

[Chris Costello]

On Sat, Jul 3, 1999, Marc Nicholas wrote:
> I would certainly welcome such info...
> 
> The info in the /proc filesystem in Linux is certainly nice. (One of the
> few things that is!).

   Nice, but misplaced.  What does PCI/system version/etc have to
do with running processes, exactly?

> -marc

-- 
Chris Costello
Backups?  We doan *NEED* no steenking baX%^~,VbKxNO CARRIER


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: USB floppy & booting

[Ollivier Robert]

According to Nick Hibma:
> Booting maybe (through BIOS support), but we do not support USB floppies
> from Y-E data yet at a later stage.

I don't really care about it afterwards but I'll probably need to at least
boot the installation floppy :-)
 
> I am working on support for it though.

Thanks !
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May  9 20:16:32 CEST 1999



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: USB floppy & booting

[Ollivier Robert]

According to Nick Hibma:
> Booting maybe (through BIOS support), but we do not support USB floppies
> from Y-E data yet at a later stage.

I don't really care about it afterwards but I'll probably need to at least
boot the installation floppy :-)
 
> I am working on support for it though.

Thanks !
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr
FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May  9 20:16:32 CEST 1999



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: devices in sysctl MIB?

[Marc Nicholas]

I would certainly welcome such info...

The info in the /proc filesystem in Linux is certainly nice. (One of the
few things that is!).


-marc


Marc Nicholas netSTOR Technologies, Inc. http://www.netstor.com
"Fast, Expandable and Affordable Internet Caching Products"
1.877.464.4776 416.979.9000 fax: 416.979.8223 cell: 416.346.9255

On Sat, 3 Jul 1999, Alfred Perlstein wrote:

> 
> Just a suggestion, perhaps there should be a dev tree in 
> sysctl with nodes for each device type then device.
> 
> interesting applications for this:
> 
> reporting on packets dropped/sent and such
> displaying connection status (duplex/100mb/10mb... etc)
> enabling/disabling power saving features
> 
> dev.iface.fxp0.ipkts = 432523
> dev.iface.fxp0.opkts = 432523
> dev.iface.fxp0.linkspeed = 100
> dev.iface.fxp0.linkmode = full-duplex
> dev.dsk.da0.tags = 32
> 
> 
> sysctl -w dev.iface.fxp0.linkmode=half-duplex
> 
> ?
> 
> -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] 
> systems administrator and programmer
> Win Telecom - http://www.wintelcom.net/
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: devices in sysctl MIB?

[Marc Nicholas]

I would certainly welcome such info...

The info in the /proc filesystem in Linux is certainly nice. (One of the
few things that is!).


-marc


Marc Nicholas netSTOR Technologies, Inc. http://www.netstor.com
"Fast, Expandable and Affordable Internet Caching Products"
1.877.464.4776 416.979.9000 fax: 416.979.8223 cell: 416.346.9255

On Sat, 3 Jul 1999, Alfred Perlstein wrote:

> 
> Just a suggestion, perhaps there should be a dev tree in 
> sysctl with nodes for each device type then device.
> 
> interesting applications for this:
> 
> reporting on packets dropped/sent and such
> displaying connection status (duplex/100mb/10mb... etc)
> enabling/disabling power saving features
> 
> dev.iface.fxp0.ipkts = 432523
> dev.iface.fxp0.opkts = 432523
> dev.iface.fxp0.linkspeed = 100
> dev.iface.fxp0.linkmode = full-duplex
> dev.dsk.da0.tags = 32
> 
> 
> sysctl -w dev.iface.fxp0.linkmode=half-duplex
> 
> ?
> 
> -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] 
> systems administrator and programmer
> Win Telecom - http://www.wintelcom.net/
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Login.conf (Whose problem is this) ?

[John Polstra]

In article <[EMAIL PROTECTED]>,
Gustavo V G C Rios  <[EMAIL PROTECTED]> wrote:
> i am trying to get a login classes for my users, so i decided to edit
> /etc/login.conf.
> 
> Among other, i have yma classes this way:
> 
> 
> shell:\
> :maxproc=5:\
> :tc=auth-default:
> 
> 
> Looking for auth-default, i saw the following:
> 
> ## Authentication methods
> ## Note that these are disabled by default, and libutil must
> ## be rebuilt with LOGIN_CAP_AUTH defined to use them.

This stuff is old and obsolete.  LOGIN_CAP_AUTH isn't supported any
more.  (It never was fully supported, actually.)  Don't use it.

> That's happened cause i turn on LOGIN_CAP_AUTH!
> My doubt is: Shouldn't it be -DLOGIN_CAP_AUTH?

Yes, of course.  That's what "with LOGIN_CAP_AUTH defined" means.
But it's broken, so don't bother.

If you want login classes all you need to do is "vipw" and insert
the correct class in the class field.  (See passwd(5) for details.)
If you want to create a new class, just edit it into your login.conf
file and then run cap_mkdb as instructed in the comment at the top
of that file.

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "No matter how cynical I get, I just can't keep up."-- Nora Ephron


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Login.conf (Whose problem is this) ?

[John Polstra]

In article <377e34f9.ca198...@tdnet.com.br>,
Gustavo V G C Rios   wrote:
> i am trying to get a login classes for my users, so i decided to edit
> /etc/login.conf.
> 
> Among other, i have yma classes this way:
> 
> 
> shell:\
> :maxproc=5:\
> :tc=auth-default:
> 
> 
> Looking for auth-default, i saw the following:
> 
> ## Authentication methods
> ## Note that these are disabled by default, and libutil must
> ## be rebuilt with LOGIN_CAP_AUTH defined to use them.

This stuff is old and obsolete.  LOGIN_CAP_AUTH isn't supported any
more.  (It never was fully supported, actually.)  Don't use it.

> That's happened cause i turn on LOGIN_CAP_AUTH!
> My doubt is: Shouldn't it be -DLOGIN_CAP_AUTH?

Yes, of course.  That's what "with LOGIN_CAP_AUTH defined" means.
But it's broken, so don't bother.

If you want login classes all you need to do is "vipw" and insert
the correct class in the class field.  (See passwd(5) for details.)
If you want to create a new class, just edit it into your login.conf
file and then run cap_mkdb as instructed in the comment at the top
of that file.

John
-- 
  John Polstra   j...@polstra.com
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "No matter how cynical I get, I just can't keep up."-- Nora Ephron


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Pictures from USENIX

[Greg Lehey]

On Saturday,  3 July 1999 at 17:28:51 -0700, John Polstra wrote:
> I put a handful of pictures from this year's USENIX conference at
> .

Hey, they're some of the best I've seen of USENIX.

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Pictures from USENIX

[Greg Lehey]

On Saturday,  3 July 1999 at 17:28:51 -0700, John Polstra wrote:
> I put a handful of pictures from this year's USENIX conference at
> .

Hey, they're some of the best I've seen of USENIX.

Greg
--
See complete headers for address, home page and phone numbers
finger g...@lemis.com for PGP public key


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Pictures from USENIX

[John Polstra]

I put a handful of pictures from this year's USENIX conference at
.

John
---
  John Polstra   j...@polstra.com
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "No matter how cynical I get, I just can't keep up."-- Nora Ephron



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Pictures from USENIX

[John Polstra]

I put a handful of pictures from this year's USENIX conference at
.

John
---
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "No matter how cynical I get, I just can't keep up."-- Nora Ephron



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to start to be a hacker?

[Tim Vanderhoek]

On Sat, Jul 03, 1999 at 01:26:30PM -0700, Janie Dykes wrote:
>
> you make excellent points.  For the most part, the novice/average
> person, believes that hackers are malicious, destructive individuals.  A
> huge number of computer users are misled and misinformed about the true
> definition of the term 'hacker'.  This is unfortunate - if those people

I don't know.  I'm not sure that's so true anymore as it once was.
I've been bugged before by kids (hehe, from my peer group, that
is) wanting to know what the best thing I'd ever done was.  After
giving some answer about some really insiduous batch files I'd written
for DOS, I was rather disappointed to find-out they meant "what
was the most illegal thing you've ever done".  I didn't really give an
answer to that, but I think many hackers have broken into a system
or done something similar at some time (probably fewer of the younger
ones since wide availability of real operating systems helps on this
ticket).  Not to let this become a passage of right or anything.
A hacker, of course, is not going to concern themselves with what
a hacker is, but others might.  The tone of this thread seems to
have been set by esr's little p/r definition of hacker.  I'd like
to declare at this time that a hacker is someone who sends me money
in the mail.  Upon these people I will bestow the title hacker.
Anyways, like I said: I'm not sure your description of the average
person's definition of "hacker" is so true anymore.  The average
person's definition is probably a little more true than esr's, if
not nearly as articulate.

PS: don't worry, you aren't expected to send much money these days
anymore.

PSS: Sending cash in the mail is illegal, don't do it.  Canadian or
 American money orders only, please.


> could spend some time reading the brilliant posts to this list, they
> might realize that we are not all 16 year olds, hiding behind the glow

Heh.  Despite the -list name, this whole thread belongs on -chat.


-- 
This is my .signature which gets appended to the end of my messages.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to start to be a hacker?

[Wes Peters]

"Brian F. Feldman" wrote:
> 
> On Sat, 3 Jul 1999, Janie Dykes wrote:
> 
> > When scouring through the threads - this one in particular caught my
> > attention.  In my experience, which is still very new, I think all of
> > you make excellent points.  For the most part, the novice/average
> > person, believes that hackers are malicious, destructive individuals.  A
> > huge number of computer users are misled and misinformed about the true
> > definition of the term 'hacker'.  This is unfortunate - if those people
> > could spend some time reading the brilliant posts to this list, they
> > might realize that we are not all 16 year olds, hiding behind the glow
> 
> *cough* Care to explain that comment?

Trust me, greenie, those of us who a FAR from 16 wish we weren't.  ;^)

You're obviously not the wastrel Janie is talking about here.  THEY're
all over at SlashDot calling me names.  ;^)

> > The
> > first time I experienced that curiosity - I got a little carried away.
> > eh hem  I learned that my skills, which included aptness
> > and dexterity, had been misdirected.  Upon my awakening, I was blessed
> > with my mentor. He challenged me to use my skills productively. 

One of the important aspects of being a hacker is discipline, both
self-discipline and team discipline when working with others.  Both 
are learned behavior for the typical hacker type; something you have
to develop an admiration for before you are even willing to try it
yourself.

A certain amount of discretion is called for as well, which can ONLY
be learned by experience.  In the meantime, a good mentor can help
by giving advice (and/or an occasional butt-kicking) to avoid doing
something REALLY stupid.

These two traits are certainly not unique to hacking, that's why
mentoring is a concept as old as the children of Adam and Eve.  In
fact, I've found it to be MUCH more important in other occupations, 
like motorcycling, sailing, and chemistry.  ;^)

> > In
> > retrospect, I learned [the hard way] and gained some experience with

Preferably without losing any body parts?

> > some help from my mentor [some of you may know Peter Mountain -
> > BRU2000].  All in all, there are many contributing factors to becoming a
> > hacker.  I rarely post to this list - so I hope that my lengthy post
> > doesn't offend.  So on that note - I will continue observing the minds
> > at work.

No problem, you're always welcome.  Do try to keep the quoting to a
minimum.  ;^)

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
http://softweyr.com/   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to start to be a hacker?

[Wes Peters]

"Brian F. Feldman" wrote:
> 
> On Sat, 3 Jul 1999, Janie Dykes wrote:
> 
> > When scouring through the threads - this one in particular caught my
> > attention.  In my experience, which is still very new, I think all of
> > you make excellent points.  For the most part, the novice/average
> > person, believes that hackers are malicious, destructive individuals.  A
> > huge number of computer users are misled and misinformed about the true
> > definition of the term 'hacker'.  This is unfortunate - if those people
> > could spend some time reading the brilliant posts to this list, they
> > might realize that we are not all 16 year olds, hiding behind the glow
> 
> *cough* Care to explain that comment?

Trust me, greenie, those of us who a FAR from 16 wish we weren't.  ;^)

You're obviously not the wastrel Janie is talking about here.  THEY're
all over at SlashDot calling me names.  ;^)

> > The
> > first time I experienced that curiosity - I got a little carried away.
> > eh hem  I learned that my skills, which included aptness
> > and dexterity, had been misdirected.  Upon my awakening, I was blessed
> > with my mentor. He challenged me to use my skills productively. 

One of the important aspects of being a hacker is discipline, both
self-discipline and team discipline when working with others.  Both 
are learned behavior for the typical hacker type; something you have
to develop an admiration for before you are even willing to try it
yourself.

A certain amount of discretion is called for as well, which can ONLY
be learned by experience.  In the meantime, a good mentor can help
by giving advice (and/or an occasional butt-kicking) to avoid doing
something REALLY stupid.

These two traits are certainly not unique to hacking, that's why
mentoring is a concept as old as the children of Adam and Eve.  In
fact, I've found it to be MUCH more important in other occupations, 
like motorcycling, sailing, and chemistry.  ;^)

> > In
> > retrospect, I learned [the hard way] and gained some experience with

Preferably without losing any body parts?

> > some help from my mentor [some of you may know Peter Mountain -
> > BRU2000].  All in all, there are many contributing factors to becoming a
> > hacker.  I rarely post to this list - so I hope that my lengthy post
> > doesn't offend.  So on that note - I will continue observing the minds
> > at work.

No problem, you're always welcome.  Do try to keep the quoting to a
minimum.  ;^)

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
http://softweyr.com/   w...@softweyr.com


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

devices in sysctl MIB?

[Alfred Perlstein]

Just a suggestion, perhaps there should be a dev tree in 
sysctl with nodes for each device type then device.

interesting applications for this:

reporting on packets dropped/sent and such
displaying connection status (duplex/100mb/10mb... etc)
enabling/disabling power saving features

dev.iface.fxp0.ipkts = 432523
dev.iface.fxp0.opkts = 432523
dev.iface.fxp0.linkspeed = 100
dev.iface.fxp0.linkmode = full-duplex
dev.dsk.da0.tags = 32


sysctl -w dev.iface.fxp0.linkmode=half-duplex

?

-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] 
systems administrator and programmer
Win Telecom - http://www.wintelcom.net/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to start to be a hacker?

[Tim Vanderhoek]

On Sat, Jul 03, 1999 at 01:26:30PM -0700, Janie Dykes wrote:
>
> you make excellent points.  For the most part, the novice/average
> person, believes that hackers are malicious, destructive individuals.  A
> huge number of computer users are misled and misinformed about the true
> definition of the term 'hacker'.  This is unfortunate - if those people

I don't know.  I'm not sure that's so true anymore as it once was.
I've been bugged before by kids (hehe, from my peer group, that
is) wanting to know what the best thing I'd ever done was.  After
giving some answer about some really insiduous batch files I'd written
for DOS, I was rather disappointed to find-out they meant "what
was the most illegal thing you've ever done".  I didn't really give an
answer to that, but I think many hackers have broken into a system
or done something similar at some time (probably fewer of the younger
ones since wide availability of real operating systems helps on this
ticket).  Not to let this become a passage of right or anything.
A hacker, of course, is not going to concern themselves with what
a hacker is, but others might.  The tone of this thread seems to
have been set by esr's little p/r definition of hacker.  I'd like
to declare at this time that a hacker is someone who sends me money
in the mail.  Upon these people I will bestow the title hacker.
Anyways, like I said: I'm not sure your description of the average
person's definition of "hacker" is so true anymore.  The average
person's definition is probably a little more true than esr's, if
not nearly as articulate.

PS: don't worry, you aren't expected to send much money these days
anymore.

PSS: Sending cash in the mail is illegal, don't do it.  Canadian or
 American money orders only, please.


> could spend some time reading the brilliant posts to this list, they
> might realize that we are not all 16 year olds, hiding behind the glow

Heh.  Despite the -list name, this whole thread belongs on -chat.


-- 
This is my .signature which gets appended to the end of my messages.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

devices in sysctl MIB?

[Alfred Perlstein]

Just a suggestion, perhaps there should be a dev tree in 
sysctl with nodes for each device type then device.

interesting applications for this:

reporting on packets dropped/sent and such
displaying connection status (duplex/100mb/10mb... etc)
enabling/disabling power saving features

dev.iface.fxp0.ipkts = 432523
dev.iface.fxp0.opkts = 432523
dev.iface.fxp0.linkspeed = 100
dev.iface.fxp0.linkmode = full-duplex
dev.dsk.da0.tags = 32


sysctl -w dev.iface.fxp0.linkmode=half-duplex

?

-Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] 
systems administrator and programmer
Win Telecom - http://www.wintelcom.net/



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

The busspace modernization initiative.

[Warner Losh]

I'm trying to update the bus-space routines to match more closely the
NetBSD routines.  The new-config project has already done this, so
I've been moving their code into a relatively pure -current tree.

I'm finding that there are many places that assume that
bus_space_handle_t is the same thing as u_int or that
bus_space_handles can be compared with !=.  Some of this code I even
wrote :-(.

These strike me as unwise assumptions.  Fortunately, it appears that
there are only 4 files impacted (at least in my config, I've not tried
GENERIC yet):
../../pci/bt_pci.c
../../i386/i386/nexus.c
../../i386/isa/aha_isa.c
../../pci/es1370.c
It strikes me as unwise to make these assumptions, even if they should
generally prove to be true.

Comments?

Warner

P.S.  Here's the diffs which are what I'm trying to do.  Please feel
free to comment on them.  I'm unsure why there is a struct resource *
in bus_space_handle_t in this implementation.  I'll have to ask on the
new-config lists, since if it isn't needed, it would best be
removed...

--- /home/imp/FreeBSD/src/sys/i386/include/bus.hSat Jul  3 14:14:08 1999
+++ ./bus.h Mon Apr 26 00:11:18 1999
@@ -107,8 +101,11 @@
 /*
  * Access methods for bus resources and address space.
  */
-typedefint bus_space_tag_t;
-typedefu_int bus_space_handle_t;
+typedef u_int bus_space_tag_t;
+typedef struct {
+u_int addr;
+struct resource *resource;
+} bus_space_handle_t;
 
 /*
  * Map a region of device bus space into CPU virtual address space.
@@ -177,10 +174,10 @@
 #if defined (_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
 #endif
-   return (inb(handle + offset));
+   return (inb(handle.addr + offset));
 #endif
 #if defined (_I386_BUS_MEMIO_H_)
-   return (*(volatile u_int8_t *)(handle + offset));
+   return (*(volatile u_int8_t *)(handle.addr + offset));
 #endif
 }
 
@@ -192,10 +189,10 @@
 #if defined(_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
 #endif
-   return (inw(handle + offset));
+   return (inw(handle.addr + offset));
 #endif
 #if defined(_I386_BUS_MEMIO_H_)
-   return (*(volatile u_int16_t *)(handle + offset));
+   return (*(volatile u_int16_t *)(handle.addr + offset));
 #endif
 }
 
@@ -207,10 +204,10 @@
 #if defined(_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
 #endif
-   return (inl(handle + offset));
+   return (inl(handle.addr + offset));
 #endif
 #if defined(_I386_BUS_MEMIO_H_)
-   return (*(volatile u_int32_t *)(handle + offset));
+   return (*(volatile u_int32_t *)(handle.addr + offset));
 #endif
 }
 
@@ -238,9 +235,10 @@
size_t count);
 
 static __inline void
-bus_space_read_multi_1(bus_space_tag_t tag, bus_space_handle_t bsh,
+bus_space_read_multi_1(bus_space_tag_t tag, bus_space_handle_t bsht,
   bus_size_t offset, u_int8_t *addr, size_t count)
 {
+   u_int bsh = bsht.addr;
 #if defined(_I386_BUS_PIO_H_)
 #if defined(_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
@@ -266,9 +264,10 @@
 }
 
 static __inline void
-bus_space_read_multi_2(bus_space_tag_t tag, bus_space_handle_t bsh,
+bus_space_read_multi_2(bus_space_tag_t tag, bus_space_handle_t bsht,
   bus_size_t offset, u_int16_t *addr, size_t count)
 {
+   u_int bsh = bsht.addr;
 #if defined(_I386_BUS_PIO_H_)
 #if defined(_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
@@ -294,9 +293,10 @@
 }
 
 static __inline void
-bus_space_read_multi_4(bus_space_tag_t tag, bus_space_handle_t bsh,
+bus_space_read_multi_4(bus_space_tag_t tag, bus_space_handle_t bsht,
   bus_size_t offset, u_int32_t *addr, size_t count)
 {
+   u_int bsh = bsht.addr;
 #if defined(_I386_BUS_PIO_H_)
 #if defined(_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
@@ -347,9 +347,10 @@
 
 
 static __inline void
-bus_space_read_region_1(bus_space_tag_t tag, bus_space_handle_t bsh,
+bus_space_read_region_1(bus_space_tag_t tag, bus_space_handle_t bsht,
bus_size_t offset, u_int8_t *addr, size_t count)
 {
+   u_int bsh = bsht.addr;
 #if defined(_I386_BUS_PIO_H_)
 #if defined(_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
@@ -384,9 +385,10 @@
 }
 
 static __inline void
-bus_space_read_region_2(bus_space_tag_t tag, bus_space_handle_t bsh,
+bus_space_read_region_2(bus_space_tag_t tag, bus_space_handle_t bsht,
bus_size_t offset, u_int16_t *addr, size_t count)
 {
+   u_int bsh = bsht.addr;
 #if defined(_I386_BUS_PIO_H_)
 #if defined(_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
@@ -421,9 +423,10 @@
 }
 
 static __inline void
-bus_space_read_region_4(bus_space_tag_t tag, bus_space_handle_t bsh,
+bus_space_read_region_4(bus_space_tag_t tag, bus_space_handle_t bsht,
bus_size_t offset, u_int32_t *addr, size_t count)
 {
+  

Re: UMAX scsi scanner on adaptec 1542 Card

[Greg Skafte]

tried it both with bios enabled and disabled  I've even tried reseting 
to factory defaults, I enabled and disabled sync negotiation, I've also tried
cutting the speed from 10 -> 5 -> 1.3 or what ever the slowest transfer rate wa




Quoting Warner Losh ([EMAIL PROTECTED])
On Subject: Re: UMAX scsi scanner on adaptec 1542 Card
Date: Fri, Jul 02, 1999 at 10:42:20PM -0600

> In message <[EMAIL PROTECTED]> Greg Skafte writes:
> : THANKS man .
> 
> A hunch.  I just tried to bring up my 1542CF with the bios disabled in
> -current and it blew chunks like you described.  Is your BIOS
> disabled?  If so, can you enable it and see if that works?  It should
> work with the bios disabled, but I know how painful that can be...
> 
> Warner
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message

-- 
Email: [EMAIL PROTECTED]   Voice: +780 413 1910Fax: +780 421 4929
   #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 
----
When things can't get any worse, they simplify themselves by getting a whole
lot worse then complicated. A complete and utter disaster is the simplest
thing in the world; it's preventing one that's complex.   (Janet Morris)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to start to be a hacker?

[Brian F. Feldman]

On Sat, 3 Jul 1999, Janie Dykes wrote:

> When scouring through the threads - this one in particular caught my
> attention.  In my experience, which is still very new, I think all of
> you make excellent points.  For the most part, the novice/average
> person, believes that hackers are malicious, destructive individuals.  A
> huge number of computer users are misled and misinformed about the true
> definition of the term 'hacker'.  This is unfortunate - if those people
> could spend some time reading the brilliant posts to this list, they
> might realize that we are not all 16 year olds, hiding behind the glow

*cough* Care to explain that comment?

> of the monitor, reading their email and stealing their passwords and
> credit card information and posting it on IRC. I have a point.  :]  The
> first time I experienced that curiosity - I got a little carried away.
> eh hem  I learned that my skills, which included aptness
> and dexterity, had been misdirected.  Upon my awakening, I was blessed
> with my mentor. He challenged me to use my skills productively.  In
> retrospect, I learned [the hard way] and gained some experience with
> some help from my mentor [some of you may know Peter Mountain -
> BRU2000].  All in all, there are many contributing factors to becoming a
> hacker.  I rarely post to this list - so I hope that my lengthy post
> doesn't offend.  So on that note - I will continue observing the minds
> at work.
> 
> Thanks for the opportunity to post -
> Janie Dykes
> 
> 
> 
>  Wes Peters wrote:
> > 
> > "G. Adam Stanislav" wrote:
> > >
> > > On Sat, Jul 03, 1999 at 01:18:52AM -0600, Wes Peters wrote:
> > > > > > You either are a hacker, or you are not. It is not something someone else
> > > > > > can teach you.
> > > > >
> > > > > This deserves a FAQ entry. What an awesome response.
> > > >
> > > > But it's certainly NOT something that you just are, either.  You have to
> > > > have talent, but you also have to have experience.  This is most often
> > > > done by a mentor.
> > >
> > > If you have the innate curiosity mentioned in my message, you will obtain
> > > experience whether you have a mentor or not. Experience is best obtained
> > > by trying things. It cannot be imparted by anyone else (although, it can
> > > be encouraged).
> > 
> > And, in some cases, disasters averted.  I think all of us here have seen
> > a few graphic examples lately of what happens when the mentoring process
> > doesn't work.
> > 
> > I think being a hacker is a combination of talent, ethics, and experience.
> > I've known talented and experienced programmers who weren't hackers,
> > either because they didn't have the innate curiousity you mention or
> > because they were ethically challenged and used their skills to steal,
> > cheat, and destroy, which are *not* part of the hacker ethos.  Hackers
> > create, crackers steal and destroy.
> > 
> > But I'm certain you new that.  ;^)
> > 
> > --
> > "Where am I, and what am I doing in this handbasket?"
> > 
> > Wes Peters Softweyr LLC
> > http://softweyr.com/   [EMAIL PROTECTED]
> > 
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Repalcement for grep(1)

[Todd Vierling]

On Sat, 3 Jul 1999, Jamie Howard wrote:

: I also do not use mmap(), I treat the file as a simple stream
: instead.  My code is also a bit slower on larger files, but a bit faster
: on smaller files.  Sometimes I am an order of magnitude slower.  I am
: never that much faster.  I think not using mmap is the reason, but I do
: not know for certain.

After the unified buffer cache modifications happen in the NetBSD kernel,
the difference will be much less noticeable.

: Now, I am having a problem though.  I cannot figure out how to implement
: -w and -x.  For -x, I tried modifying the regular expression (foo) into
: ^(foo)$ before compiling, but that did not work.  I intended to do
: something similar with -w.  Anyway, I am probably missing the obvious, but
: does anyone have any ideas regarding how I should implement -w and -x?

Hm.  Adding ^ and $ should work, provided you don't specify either
REG_NOTBOL or REG_NOTEOL.  (I assume that (foo) above, including the parens,
is the RE.  With the parens, it depends whether you're using standard REs or
extended REs.  :)

Thatnks for this work ... I'll leave it to another soul to do something with
it in NetBSD.

-- 
-- Todd Vierling ([EMAIL PROTECTED])



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to start to be a hacker?

[Janie Dykes]

When scouring through the threads - this one in particular caught my
attention.  In my experience, which is still very new, I think all of
you make excellent points.  For the most part, the novice/average
person, believes that hackers are malicious, destructive individuals.  A
huge number of computer users are misled and misinformed about the true
definition of the term 'hacker'.  This is unfortunate - if those people
could spend some time reading the brilliant posts to this list, they
might realize that we are not all 16 year olds, hiding behind the glow
of the monitor, reading their email and stealing their passwords and
credit card information and posting it on IRC. I have a point.  :]  The
first time I experienced that curiosity - I got a little carried away.
eh hem  I learned that my skills, which included aptness
and dexterity, had been misdirected.  Upon my awakening, I was blessed
with my mentor. He challenged me to use my skills productively.  In
retrospect, I learned [the hard way] and gained some experience with
some help from my mentor [some of you may know Peter Mountain -
BRU2000].  All in all, there are many contributing factors to becoming a
hacker.  I rarely post to this list - so I hope that my lengthy post
doesn't offend.  So on that note - I will continue observing the minds
at work.

Thanks for the opportunity to post -
Janie Dykes



 Wes Peters wrote:
> 
> "G. Adam Stanislav" wrote:
> >
> > On Sat, Jul 03, 1999 at 01:18:52AM -0600, Wes Peters wrote:
> > > > > You either are a hacker, or you are not. It is not something someone else
> > > > > can teach you.
> > > >
> > > > This deserves a FAQ entry. What an awesome response.
> > >
> > > But it's certainly NOT something that you just are, either.  You have to
> > > have talent, but you also have to have experience.  This is most often
> > > done by a mentor.
> >
> > If you have the innate curiosity mentioned in my message, you will obtain
> > experience whether you have a mentor or not. Experience is best obtained
> > by trying things. It cannot be imparted by anyone else (although, it can
> > be encouraged).
> 
> And, in some cases, disasters averted.  I think all of us here have seen
> a few graphic examples lately of what happens when the mentoring process
> doesn't work.
> 
> I think being a hacker is a combination of talent, ethics, and experience.
> I've known talented and experienced programmers who weren't hackers,
> either because they didn't have the innate curiousity you mention or
> because they were ethically challenged and used their skills to steal,
> cheat, and destroy, which are *not* part of the hacker ethos.  Hackers
> create, crackers steal and destroy.
> 
> But I'm certain you new that.  ;^)
> 
> --
> "Where am I, and what am I doing in this handbasket?"
> 
> Wes Peters Softweyr LLC
> http://softweyr.com/   [EMAIL PROTECTED]
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: BUG boot-time messages

[Matthew Hunt]

On Sat, Jul 03, 1999 at 02:00:31PM -0400, Brian F. Feldman wrote:

> > The spelling of "failed" is totally incorrect, and it would sure be
> > nice to see the spelling corrected on a future release.
> 
> I don't see that in FreeBSD's HEAD, RELENG_2_2, or RELENG_3 branches.

revision 1.7
date: 1999/04/06 21:15:18;  author: phk;  state: Exp;  lines: +2 -2
failled spell-check

revision 1.5.2.2
date: 1999/05/23 18:59:50;  author: gibbs;  state: Exp;  lines: +2 -2
failled->failed

Submitted by:   [EMAIL PROTECTED]

-- 
Matthew Hunt <[EMAIL PROTECTED]> * Inertia is a property
http://www.pobox.com/~mph/   * of matter.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: UMAX scsi scanner on adaptec 1542 Card

[Greg Skafte]

tried it both with bios enabled and disabled  I've even tried reseting 
to factory defaults, I enabled and disabled sync negotiation, I've also tried
cutting the speed from 10 -> 5 -> 1.3 or what ever the slowest transfer rate wa




Quoting Warner Losh (i...@harmony.village.org)
On Subject: Re: UMAX scsi scanner on adaptec 1542 Card
Date: Fri, Jul 02, 1999 at 10:42:20PM -0600

> In message <19990702184559.e25...@gras-varg.worldgate.com> Greg Skafte writes:
> : THANKS man .
> 
> A hunch.  I just tried to bring up my 1542CF with the bios disabled in
> -current and it blew chunks like you described.  Is your BIOS
> disabled?  If so, can you enable it and see if that works?  It should
> work with the bios disabled, but I know how painful that can be...
> 
> Warner
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message

-- 
Email: ska...@worldgate.com   Voice: +780 413 1910Fax: +780 421 4929
   #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 
----
When things can't get any worse, they simplify themselves by getting a whole
lot worse then complicated. A complete and utter disaster is the simplest
thing in the world; it's preventing one that's complex.   (Janet Morris)


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: BUG boot-time messages

[Kenneth D. Merry]

Brian F. Feldman wrote...
> On Sat, 3 Jul 1999, Jim Pazarena wrote:
> 
> > The following messages appear on the display as my FreeBSD machine is
> > booting.
> > 
> > The spelling of "failed" is totally incorrect, and it would sure be
> > nice to see the spelling corrected on a future release.
> 
> I don't see that in FreeBSD's HEAD, RELENG_2_2, or RELENG_3 branches.
> 
> > 
> > To: [EMAIL PROTECTED]
> > Subject: BUG boot-time messages
> > From: Charlie Root <[EMAIL PROTECTED]>
> > Date: Sat, 3 Jul 1999 10:01:34 -0700
> > --
> > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x330
> > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x334
> > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x230
> > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x234
> > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x130
> > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x134
> >  ^^^
> > 

It was fixed in -current in April by phk, and merged to -stable by Justin
in May.

Ken
-- 
Kenneth Merry
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to start to be a hacker?

[Brian F. Feldman]

On Sat, 3 Jul 1999, Janie Dykes wrote:

> When scouring through the threads - this one in particular caught my
> attention.  In my experience, which is still very new, I think all of
> you make excellent points.  For the most part, the novice/average
> person, believes that hackers are malicious, destructive individuals.  A
> huge number of computer users are misled and misinformed about the true
> definition of the term 'hacker'.  This is unfortunate - if those people
> could spend some time reading the brilliant posts to this list, they
> might realize that we are not all 16 year olds, hiding behind the glow

*cough* Care to explain that comment?

> of the monitor, reading their email and stealing their passwords and
> credit card information and posting it on IRC. I have a point.  :]  The
> first time I experienced that curiosity - I got a little carried away.
> eh hem  I learned that my skills, which included aptness
> and dexterity, had been misdirected.  Upon my awakening, I was blessed
> with my mentor. He challenged me to use my skills productively.  In
> retrospect, I learned [the hard way] and gained some experience with
> some help from my mentor [some of you may know Peter Mountain -
> BRU2000].  All in all, there are many contributing factors to becoming a
> hacker.  I rarely post to this list - so I hope that my lengthy post
> doesn't offend.  So on that note - I will continue observing the minds
> at work.
> 
> Thanks for the opportunity to post -
> Janie Dykes
> 
> 
> 
>  Wes Peters wrote:
> > 
> > "G. Adam Stanislav" wrote:
> > >
> > > On Sat, Jul 03, 1999 at 01:18:52AM -0600, Wes Peters wrote:
> > > > > > You either are a hacker, or you are not. It is not something 
> > > > > > someone else
> > > > > > can teach you.
> > > > >
> > > > > This deserves a FAQ entry. What an awesome response.
> > > >
> > > > But it's certainly NOT something that you just are, either.  You have to
> > > > have talent, but you also have to have experience.  This is most often
> > > > done by a mentor.
> > >
> > > If you have the innate curiosity mentioned in my message, you will obtain
> > > experience whether you have a mentor or not. Experience is best obtained
> > > by trying things. It cannot be imparted by anyone else (although, it can
> > > be encouraged).
> > 
> > And, in some cases, disasters averted.  I think all of us here have seen
> > a few graphic examples lately of what happens when the mentoring process
> > doesn't work.
> > 
> > I think being a hacker is a combination of talent, ethics, and experience.
> > I've known talented and experienced programmers who weren't hackers,
> > either because they didn't have the innate curiousity you mention or
> > because they were ethically challenged and used their skills to steal,
> > cheat, and destroy, which are *not* part of the hacker ethos.  Hackers
> > create, crackers steal and destroy.
> > 
> > But I'm certain you new that.  ;^)
> > 
> > --
> > "Where am I, and what am I doing in this handbasket?"
> > 
> > Wes Peters Softweyr 
> > LLC
> > http://softweyr.com/   
> > w...@softweyr.com
> > 
> > To Unsubscribe: send mail to majord...@freebsd.org
> > with "unsubscribe freebsd-hackers" in the body of the message
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: BUG boot-time messages

[Brian F. Feldman]

On Sat, 3 Jul 1999, Kenneth D. Merry wrote:

> Brian F. Feldman wrote...
> > On Sat, 3 Jul 1999, Jim Pazarena wrote:
> > 
> > > The following messages appear on the display as my FreeBSD machine is
> > > booting.
> > > 
> > > The spelling of "failed" is totally incorrect, and it would sure be
> > > nice to see the spelling corrected on a future release.
> > 
> > I don't see that in FreeBSD's HEAD, RELENG_2_2, or RELENG_3 branches.
> > 
> > > 
> > > To: [EMAIL PROTECTED]
> > > Subject: BUG boot-time messages
> > > From: Charlie Root <[EMAIL PROTECTED]>
> > > Date: Sat, 3 Jul 1999 10:01:34 -0700
> > > --
> > > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x330
> > > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x334
> > > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x230
> > > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x234
> > > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x130
> > > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x134
> > >  ^^^
> > > 
> 
> It was fixed in -current in April by phk, and merged to -stable by Justin
> in May.
> 

Good reason for me not to see it ;)

> Ken
> -- 
> Kenneth Merry
> [EMAIL PROTECTED]
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

The busspace modernization initiative.

[Warner Losh]

I'm trying to update the bus-space routines to match more closely the
NetBSD routines.  The new-config project has already done this, so
I've been moving their code into a relatively pure -current tree.

I'm finding that there are many places that assume that
bus_space_handle_t is the same thing as u_int or that
bus_space_handles can be compared with !=.  Some of this code I even
wrote :-(.

These strike me as unwise assumptions.  Fortunately, it appears that
there are only 4 files impacted (at least in my config, I've not tried
GENERIC yet):
../../pci/bt_pci.c
../../i386/i386/nexus.c
../../i386/isa/aha_isa.c
../../pci/es1370.c
It strikes me as unwise to make these assumptions, even if they should
generally prove to be true.

Comments?

Warner

P.S.  Here's the diffs which are what I'm trying to do.  Please feel
free to comment on them.  I'm unsure why there is a struct resource *
in bus_space_handle_t in this implementation.  I'll have to ask on the
new-config lists, since if it isn't needed, it would best be
removed...

--- /home/imp/FreeBSD/src/sys/i386/include/bus.hSat Jul  3 14:14:08 1999
+++ ./bus.h Mon Apr 26 00:11:18 1999
@@ -107,8 +101,11 @@
 /*
  * Access methods for bus resources and address space.
  */
-typedefint bus_space_tag_t;
-typedefu_int bus_space_handle_t;
+typedef u_int bus_space_tag_t;
+typedef struct {
+u_int addr;
+struct resource *resource;
+} bus_space_handle_t;
 
 /*
  * Map a region of device bus space into CPU virtual address space.
@@ -177,10 +174,10 @@
 #if defined (_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
 #endif
-   return (inb(handle + offset));
+   return (inb(handle.addr + offset));
 #endif
 #if defined (_I386_BUS_MEMIO_H_)
-   return (*(volatile u_int8_t *)(handle + offset));
+   return (*(volatile u_int8_t *)(handle.addr + offset));
 #endif
 }
 
@@ -192,10 +189,10 @@
 #if defined(_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
 #endif
-   return (inw(handle + offset));
+   return (inw(handle.addr + offset));
 #endif
 #if defined(_I386_BUS_MEMIO_H_)
-   return (*(volatile u_int16_t *)(handle + offset));
+   return (*(volatile u_int16_t *)(handle.addr + offset));
 #endif
 }
 
@@ -207,10 +204,10 @@
 #if defined(_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
 #endif
-   return (inl(handle + offset));
+   return (inl(handle.addr + offset));
 #endif
 #if defined(_I386_BUS_MEMIO_H_)
-   return (*(volatile u_int32_t *)(handle + offset));
+   return (*(volatile u_int32_t *)(handle.addr + offset));
 #endif
 }
 
@@ -238,9 +235,10 @@
size_t count);
 
 static __inline void
-bus_space_read_multi_1(bus_space_tag_t tag, bus_space_handle_t bsh,
+bus_space_read_multi_1(bus_space_tag_t tag, bus_space_handle_t bsht,
   bus_size_t offset, u_int8_t *addr, size_t count)
 {
+   u_int bsh = bsht.addr;
 #if defined(_I386_BUS_PIO_H_)
 #if defined(_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
@@ -266,9 +264,10 @@
 }
 
 static __inline void
-bus_space_read_multi_2(bus_space_tag_t tag, bus_space_handle_t bsh,
+bus_space_read_multi_2(bus_space_tag_t tag, bus_space_handle_t bsht,
   bus_size_t offset, u_int16_t *addr, size_t count)
 {
+   u_int bsh = bsht.addr;
 #if defined(_I386_BUS_PIO_H_)
 #if defined(_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
@@ -294,9 +293,10 @@
 }
 
 static __inline void
-bus_space_read_multi_4(bus_space_tag_t tag, bus_space_handle_t bsh,
+bus_space_read_multi_4(bus_space_tag_t tag, bus_space_handle_t bsht,
   bus_size_t offset, u_int32_t *addr, size_t count)
 {
+   u_int bsh = bsht.addr;
 #if defined(_I386_BUS_PIO_H_)
 #if defined(_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
@@ -347,9 +347,10 @@
 
 
 static __inline void
-bus_space_read_region_1(bus_space_tag_t tag, bus_space_handle_t bsh,
+bus_space_read_region_1(bus_space_tag_t tag, bus_space_handle_t bsht,
bus_size_t offset, u_int8_t *addr, size_t count)
 {
+   u_int bsh = bsht.addr;
 #if defined(_I386_BUS_PIO_H_)
 #if defined(_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
@@ -384,9 +385,10 @@
 }
 
 static __inline void
-bus_space_read_region_2(bus_space_tag_t tag, bus_space_handle_t bsh,
+bus_space_read_region_2(bus_space_tag_t tag, bus_space_handle_t bsht,
bus_size_t offset, u_int16_t *addr, size_t count)
 {
+   u_int bsh = bsht.addr;
 #if defined(_I386_BUS_PIO_H_)
 #if defined(_I386_BUS_MEMIO_H_)
if (tag == I386_BUS_SPACE_IO)
@@ -421,9 +423,10 @@
 }
 
 static __inline void
-bus_space_read_region_4(bus_space_tag_t tag, bus_space_handle_t bsh,
+bus_space_read_region_4(bus_space_tag_t tag, bus_space_handle_t bsht,
bus_size_t offset, u_int32_t *addr, size_t count)
 {
+   

Re: bpfilter -> bpf patches [LONG]

[Dag-Erling Smorgrav]

Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> That said, thanks for asking - while looking into this matter I found
> another problem :) new patches will be available soon.

Nothing serious; a corrected patch is available on my freefall web
page (http://www.freebsd.org/~des/software/)

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Porting LILO to FreeBSD

[Warner Losh]

In message <[EMAIL PROTECTED]> Mike Smith writes:
: Neither; he'll have to tell the BIOS that the drive's not there.

That's what he's doing right now...  He doesn't want to keep doing
this since it is such a PITA.

However, other posters in the thread gave me enough hints that I think
that I can help him make it work.  LILO's trick of installing a small
translating shim on INT 13 may be just the ticket...

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Porting LILO to FreeBSD

[Mike Smith]

> In message <[EMAIL PROTECTED]> Graham Wheeler writes:
> : The only reason I even want to do this is that I still have a number
> : of old DOS games that won't work under Win95. And dosemu and Wine
> : just don't cut it either, unfortunately.
> 
> I have a friend that wants to boot FreeBSD on his IDE drive, or Win95
> on his SCSI drive.  No, it isn't an option to swap them, so the SCSI
> drive winds up being 'D'.  The only way he can boot Win95 is to
> completely disable the IDE drive from the BIOS' point of view :-(.
> 
> Would osbs solve this problem, or would he have to take a look at
> LILO?

Neither; he'll have to tell the BIOS that the drive's not there.

-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  [EMAIL PROTECTED]
\\-- Joseph Merrick   \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: USB floppy & booting

[Nick Hibma]

Booting maybe (through BIOS support), but we do not support USB floppies
from Y-E data yet at a later stage.

I am working on support for it though.

Nick


On Sat, 3 Jul 1999, Ollivier Robert wrote:

> Do we support booting from USB floppies ? I plan to buy one of the new VAIOs
> (probably the Z505S with Celeron/333 + 64 MB + 12.1" screen) and it seems to
> come with an USB floppy (as opposed to the probably-IDE of former models).
> 
> They've apparently ditched both the PS/2 mouse and the IDE floppy and moved to 
> 2x USB ports...
> -- 
> Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
> FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May  9 20:16:32 CEST 1999
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 
> 

-- 
e-Mail: [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to start to be a hacker?

[G. Adam Stanislav]

On Sat, Jul 03, 1999 at 11:45:41AM -0600, Wes Peters wrote:
> And, in some cases, disasters averted.  I think all of us here have seen
> a few graphic examples lately of what happens when the mentoring process
> doesn't work.

Sadly, mentoring can occasionaly hurt the mentor, too.

I used to work for a company whose only programmer quit. They made
testing machines controlled by a computer. All of their software
was written in Turbo Pascal under MS DOS, and very poorly at that.

I was hired along with a young man who had just graduated from college.
The first thing I did was convince the boss to toss Turbo Pascal and
switch to a combination of C and assembly language.

The second thing I had to do was convince him not to fire the young
man. He majored in physics and had a few programming classes which
gave him the false impression he could program computers.

He was completely lost. The boss wanted to fire him because "we
don't run a charity here." I thought the young man was intelligent
and could learn. I helped him a lot, taught him many tricks. I
think I turned him into a fairly decent programmer (not a hacker,
mind you, because programming was a job to him, not a passion).

Two years later I was "laid off." The boss figured he no longer
needed both of us, and decided to keep the younger one because
he did not have to pay him as much as me.

The story had a happy ending after all: When the young man saw what
the boss did to me, within a few months he got a job with another
company and quit. So I think I did teach him well. :-)

> I think being a hacker is a combination of talent, ethics, and experience.

That's a good way of putting it.

> I've known talented and experienced programmers who weren't hackers,
> either because they didn't have the innate curiousity you mention or
> because they were ethically challenged and used their skills to steal,
> cheat, and destroy, which are *not* part of the hacker ethos.  Hackers
> create, crackers steal and destroy.

Agreed.

Adam


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Repalcement for grep(1)

[Todd Vierling]

On Sat, 3 Jul 1999, Jamie Howard wrote:

: I also do not use mmap(), I treat the file as a simple stream
: instead.  My code is also a bit slower on larger files, but a bit faster
: on smaller files.  Sometimes I am an order of magnitude slower.  I am
: never that much faster.  I think not using mmap is the reason, but I do
: not know for certain.

After the unified buffer cache modifications happen in the NetBSD kernel,
the difference will be much less noticeable.

: Now, I am having a problem though.  I cannot figure out how to implement
: -w and -x.  For -x, I tried modifying the regular expression (foo) into
: ^(foo)$ before compiling, but that did not work.  I intended to do
: something similar with -w.  Anyway, I am probably missing the obvious, but
: does anyone have any ideas regarding how I should implement -w and -x?

Hm.  Adding ^ and $ should work, provided you don't specify either
REG_NOTBOL or REG_NOTEOL.  (I assume that (foo) above, including the parens,
is the RE.  With the parens, it depends whether you're using standard REs or
extended REs.  :)

Thatnks for this work ... I'll leave it to another soul to do something with
it in NetBSD.

-- 
-- Todd Vierling (t...@pobox.com)



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Repalcement for grep(1)

[Jamie Howard]

I have used FreeBSD for a couple years now.  It is the only OS on my
desktop.  I have learnt many things from its source.  I felt it was time
to give something back.  A few minutes later I decided to offer it to all
BSDs.  I also will offer it to the DaemonLinux group, Apple, the  Darwin
group, and Tenon Systems, after public acceptence.  If there is anyone
else out there using a BSD base and GNU grep, they can have it too.

Looking aroud, I thought it would be great to try to replace one of the
GNU utilites included in the base with a version which is freely
redistributable.  I figured a compiler was beyond me, but a a couple of
the simpler utilities caught my eye.  Grep was first.

All of the code is original except for binary.c.  It is used with the -a
option to prevent searching binary files.  binary.c is extricated from
less-332's binary checking code.  I was just that lazy.

I made the version in FreeBSD 4.0 my target except for -A num, -B num, -C,
-num, and -Z.  These are not required by the Single Unix Specification or
POSIX and I felt they would bloat my code too significantly.  

I added the -o option from 4.4BSD-Lite2's implementation of egrep.  I also
stole it's man page.

One of the primary concerns was simplicity.  Looking through the code, you
should nobody should have any difficuly understanding the code.  Regex
does all the heavy work.  The object code is about 16% of the size of GNU 
grep.  I also do not use mmap(), I treat the file as a simple stream
instead.  My code is also a bit slower on larger files, but a bit faster
on smaller files.  Sometimes I am an order of magnitude slower.  I am
never that much faster.  I think not using mmap is the reason, but I do
not know for certain.

Now, I am having a problem though.  I cannot figure out how to implement
-w and -x.  For -x, I tried modifying the regular expression (foo) into
^(foo)$ before compiling, but that did not work.  I intended to do
something similar with -w.  Anyway, I am probably missing the obvious, but
does anyone have any ideas regarding how I should implement -w and -x?

If anyone can help with the -w and -x problems, would like to test, or has
any other comments, let me know.  I'd also like advice on the speed
issue.  Also, since I am at it, if you want anything added, lay it on me,
either code or ideas.  :)

The source code can be found at 

ftp://ftp.wam.umd.edu/pub/howardjp/grep-0.2.tar.gz

The source was written and tested on a FreeBSD 3.2 system.  I have also
compiled under BSDi 3.1.  It should work on any BSD and most any Unix.
The Makefile is written in the style of the rest of the FreeBSD utilites
so that it can be dropped right into /usr/src/usr.bin someday.  Only minor
modifications should be needed for BSDi, NetBSD, and OpenBSD.  I have not
built this on either NetBSD or OpenBSD but expect no problems.  If anyone
does have problems please let me know.  Fixes are even better. 

Thank you everyone, Jamie




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Login.conf (Whose problem is this) ?

[Gustavo V G C Rios]

i am trying to get a login classes for my users, so i decided to edit
/etc/login.conf.

Among other, i have yma classes this way:


shell:\
:maxproc=5:\
:tc=auth-default:


Looking for auth-default, i saw the following:

## Authentication methods
## Note that these are disabled by default, and libutil must
## be rebuilt with LOGIN_CAP_AUTH defined to use them.
#
#auth-defaults:\
#   :auth=krb_skey_or_passwd,passwd,kerberos,skey:
#
#auth-root-defaults:\
#   :auth-login=krb_skey_or_passwd,passwd,kerberos,skey:\
#   :auth-rlogin=krb_or_skey,kerberos,skey:
#
#auth-ftp-defaults:\
#   :auth=skey_or_pwd,passwd,skey:
#
#


Ok, so i need LOGIN_CAP_AUTH in libutil, i went to /usr/src/lib/libutil
and changed, Makefile:

From: 
#   @(#)Makefile8.1 (Berkeley) 6/4/93

LIB=util
SHLIB_MAJOR= 2
SHLIB_MINOR= 2
CFLAGS+=-Wall -DLIBC_SCCS -I${.CURDIR} -I${.CURDIR}/../../sys
#CFLAGS+=LOGIN_CAP_AUTH 

To:
#   @(#)Makefile8.1 (Berkeley) 6/4/93

LIB=util
SHLIB_MAJOR= 2
SHLIB_MINOR= 2
CFLAGS+=-Wall -DLIBC_SCCS -I${.CURDIR} -I${.CURDIR}/../../sys
CFLAGS+=LOGIN_CAP_AUTH 

Here came the problem:

myname# make
cc -O -pipe -Wall -DLIBC_SCCS -I/usr/src/lib/libutil
-I/usr/src/lib/libutil/../../sys LOGIN_CAP_AUTH -c
/usr/src/lib/libutil/login.c -o login.o
cc: LOGIN_CAP_AUTH: No such file or directory
*** Error code 1

Stop.


That's happened cause i turn on LOGIN_CAP_AUTH!
My doubt is: Shouldn't it be -DLOGIN_CAP_AUTH?

Is it right ? Can i use:

#   @(#)Makefile8.1 (Berkeley) 6/4/93

LIB=util
SHLIB_MAJOR= 2
SHLIB_MINOR= 2
CFLAGS+=-Wall -DLIBC_SCCS -I${.CURDIR} -I${.CURDIR}/../../sys
CFLAGS+=-DLOGIN_CAP_AUTH 


Is that a FreeBSD error or my one?


-- 
What about something different this year:
Crash your FreeBSD box!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: BUG boot-time messages

[Matthew Hunt]

On Sat, Jul 03, 1999 at 02:00:31PM -0400, Brian F. Feldman wrote:

> > The spelling of "failed" is totally incorrect, and it would sure be
> > nice to see the spelling corrected on a future release.
> 
> I don't see that in FreeBSD's HEAD, RELENG_2_2, or RELENG_3 branches.

revision 1.7
date: 1999/04/06 21:15:18;  author: phk;  state: Exp;  lines: +2 -2
failled spell-check

revision 1.5.2.2
date: 1999/05/23 18:59:50;  author: gibbs;  state: Exp;  lines: +2 -2
failled->failed

Submitted by:   em...@ucdavis.edu

-- 
Matthew Hunt  * Inertia is a property
http://www.pobox.com/~mph/   * of matter.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to start to be a hacker?

[Janie Dykes]

When scouring through the threads - this one in particular caught my
attention.  In my experience, which is still very new, I think all of
you make excellent points.  For the most part, the novice/average
person, believes that hackers are malicious, destructive individuals.  A
huge number of computer users are misled and misinformed about the true
definition of the term 'hacker'.  This is unfortunate - if those people
could spend some time reading the brilliant posts to this list, they
might realize that we are not all 16 year olds, hiding behind the glow
of the monitor, reading their email and stealing their passwords and
credit card information and posting it on IRC. I have a point.  :]  The
first time I experienced that curiosity - I got a little carried away.
eh hem  I learned that my skills, which included aptness
and dexterity, had been misdirected.  Upon my awakening, I was blessed
with my mentor. He challenged me to use my skills productively.  In
retrospect, I learned [the hard way] and gained some experience with
some help from my mentor [some of you may know Peter Mountain -
BRU2000].  All in all, there are many contributing factors to becoming a
hacker.  I rarely post to this list - so I hope that my lengthy post
doesn't offend.  So on that note - I will continue observing the minds
at work.

Thanks for the opportunity to post -
Janie Dykes



 Wes Peters wrote:
> 
> "G. Adam Stanislav" wrote:
> >
> > On Sat, Jul 03, 1999 at 01:18:52AM -0600, Wes Peters wrote:
> > > > > You either are a hacker, or you are not. It is not something someone 
> > > > > else
> > > > > can teach you.
> > > >
> > > > This deserves a FAQ entry. What an awesome response.
> > >
> > > But it's certainly NOT something that you just are, either.  You have to
> > > have talent, but you also have to have experience.  This is most often
> > > done by a mentor.
> >
> > If you have the innate curiosity mentioned in my message, you will obtain
> > experience whether you have a mentor or not. Experience is best obtained
> > by trying things. It cannot be imparted by anyone else (although, it can
> > be encouraged).
> 
> And, in some cases, disasters averted.  I think all of us here have seen
> a few graphic examples lately of what happens when the mentoring process
> doesn't work.
> 
> I think being a hacker is a combination of talent, ethics, and experience.
> I've known talented and experienced programmers who weren't hackers,
> either because they didn't have the innate curiousity you mention or
> because they were ethically challenged and used their skills to steal,
> cheat, and destroy, which are *not* part of the hacker ethos.  Hackers
> create, crackers steal and destroy.
> 
> But I'm certain you new that.  ;^)
> 
> --
> "Where am I, and what am I doing in this handbasket?"
> 
> Wes Peters Softweyr 
> LLC
> http://softweyr.com/   
> w...@softweyr.com
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: BUG boot-time messages

[Brian F. Feldman]

On Sat, 3 Jul 1999, Kenneth D. Merry wrote:

> Brian F. Feldman wrote...
> > On Sat, 3 Jul 1999, Jim Pazarena wrote:
> > 
> > > The following messages appear on the display as my FreeBSD machine is
> > > booting.
> > > 
> > > The spelling of "failed" is totally incorrect, and it would sure be
> > > nice to see the spelling corrected on a future release.
> > 
> > I don't see that in FreeBSD's HEAD, RELENG_2_2, or RELENG_3 branches.
> > 
> > > 
> > > To: p...@mail.qcislands.net
> > > Subject: BUG boot-time messages
> > > From: Charlie Root 
> > > Date: Sat, 3 Jul 1999 10:01:34 -0700
> > > --
> > > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x330
> > > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x334
> > > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x230
> > > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x234
> > > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x130
> > > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x134
> > >  ^^^
> > >   
> > >   
> 
> It was fixed in -current in April by phk, and merged to -stable by Justin
> in May.
> 

Good reason for me not to see it ;)

> Ken
> -- 
> Kenneth Merry
> k...@plutotech.com
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: BUG boot-time messages

[Kenneth D. Merry]

Brian F. Feldman wrote...
> On Sat, 3 Jul 1999, Jim Pazarena wrote:
> 
> > The following messages appear on the display as my FreeBSD machine is
> > booting.
> > 
> > The spelling of "failed" is totally incorrect, and it would sure be
> > nice to see the spelling corrected on a future release.
> 
> I don't see that in FreeBSD's HEAD, RELENG_2_2, or RELENG_3 branches.
> 
> > 
> > To: p...@mail.qcislands.net
> > Subject: BUG boot-time messages
> > From: Charlie Root 
> > Date: Sat, 3 Jul 1999 10:01:34 -0700
> > --
> > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x330
> > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x334
> > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x230
> > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x234
> > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x130
> > Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x134
> >  ^^^
> > 
> > 

It was fixed in -current in April by phk, and merged to -stable by Justin
in May.

Ken
-- 
Kenneth Merry
k...@plutotech.com


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: USB floppy & booting

[Nick Hibma]

Booting maybe (through BIOS support), but we do not support USB floppies
from Y-E data yet at a later stage.

I am working on support for it though.

Nick


On Sat, 3 Jul 1999, Ollivier Robert wrote:

> Do we support booting from USB floppies ? I plan to buy one of the new VAIOs
> (probably the Z505S with Celeron/333 + 64 MB + 12.1" screen) and it seems to
> come with an USB floppy (as opposed to the probably-IDE of former models).
> 
> They've apparently ditched both the PS/2 mouse and the IDE floppy and moved 
> to 
> 2x USB ports...
> -- 
> Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr
> FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May  9 20:16:32 CEST 1999
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 
> 

-- 
e-Mail: hi...@skylink.it



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: BUG boot-time messages

[Brian F. Feldman]

On Sat, 3 Jul 1999, Jim Pazarena wrote:

> The following messages appear on the display as my FreeBSD machine is
> booting.
> 
> The spelling of "failed" is totally incorrect, and it would sure be
> nice to see the spelling corrected on a future release.

I don't see that in FreeBSD's HEAD, RELENG_2_2, or RELENG_3 branches.

> 
> To: [EMAIL PROTECTED]
> Subject: BUG boot-time messages
> From: Charlie Root <[EMAIL PROTECTED]>
> Date: Sat, 3 Jul 1999 10:01:34 -0700
> --
> Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x330
> Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x334
> Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x230
> Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x234
> Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x130
> Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x134
>  ^^^
> 
> --
> Jim Pazarena   mailto:[EMAIL PROTECTED]
>http://www.qcislands.net/paz
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: bpfilter -> bpf patches [LONG]

[Dag-Erling Smorgrav]

Doug <[EMAIL PROTECTED]> writes:
>   Forgive me if this is a stupid question, but are there any circumstances
> where naming the kernel include file "bpf.h" would conflict with
> /usr/include/net/bpf.h? 

I don't think so. The bpf.h created by config(8) resides in the
compile directory and is only used there; the "real" bpf.h is in
/sys/net/ (or /usr/include/net) and is only referred to as net/bpf.h.

Besides, if there were any confusion, I wouldn't (shouldn't) have been
able to build LINT and GENERIC with the patches.

That said, thanks for asking - while looking into this matter I found
another problem :) new patches will be available soon.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Wes Peters]

"Brian F. Feldman" wrote:
> 
> On Sat, 3 Jul 1999, Jonathan Lemon wrote:
> 
> > On Jul 07, 1999 at 01:01:07AM -0400, Brian F. Feldman wrote:
> > > On Fri, 2 Jul 1999, Jonathan Lemon wrote:
> >
> > > > As for new code, use whichever you are comfortable with.  Personally, I
> > > > would recommend poll(), since it provides some added functionality over
> > > > select() that makes for easier programming.
> > >
> > > poll() is a huge pain to use, which is why I recommend select().
> >
> > Whichever you're comfortable with.  poll() isn't a pain once you know
> > how to use it, and it does bring additional benefits.
> 
> I don't see how you can not find poll() a pain when compared to select(). It
> requires so much set-up, much like (for instance) aio_write() as opposed to
> write(). I suppose if you're masochistic, you won't mind doing that :)

He wouldn't be a programmer unless masochistic.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
http://softweyr.com/   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

[PATCH] Preprocessor support for ipfw

[Ruslan Ermilov]

Hi!

There is one problem with ``preprocessor support for ipfw''.

relay# ls -l 100
ls: 100: No such file or directory
relay# ipfw list 100
00100 allow ip from any to any via lo0
relay# touch 100
relay# ipfw list 100
ipfw: error: extraneous filename arguments
[...]

Please review the attached patch.

Thanks,
-- 
Ruslan Ermilov  Sysadmin and DBA of the
[EMAIL PROTECTED]United Commercial Bank,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.247.647Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age


Index: ipfw.8
===
RCS file: /usr/FreeBSD-CVS/src/sbin/ipfw/ipfw.8,v
retrieving revision 1.54
diff -c -r1.54 ipfw.8
*** ipfw.8  1999/06/19 18:43:18 1.54
--- ipfw.8  1999/07/03 17:35:18
***
*** 15,21 
  .Op Fl D Ar macro Ns Op Ns =value
  .Op Fl U Ar macro
  .Oc
! .Ar file
  .Nm ipfw
  .Oo
  .Fl f
--- 15,21 
  .Op Fl D Ar macro Ns Op Ns =value
  .Op Fl U Ar macro
  .Oc
! .Fl F Ar file
  .Nm ipfw
  .Oo
  .Fl f
Index: ipfw.c
===
RCS file: /usr/FreeBSD-CVS/src/sbin/ipfw/ipfw.c,v
retrieving revision 1.71
diff -c -r1.71 ipfw.c
*** ipfw.c  1999/06/19 18:43:15 1.71
--- ipfw.c  1999/07/03 17:35:18
***
*** 58,65 
  #include 
  #include 
  
- int   lineno = -1;
- 
  int   s;  /* main RAW socket */
  int   do_resolv=0;/* Would try to resolve all */
  int   do_acct=0;  /* Show packet/byte count  */
--- 58,63 
***
*** 1549,1556 
  #define WHITESP   " \t\f\v\n\r"
charbuf[BUFSIZ];
char*a, *p, *args[MAX_ARGS], *cmd = NULL;
!   charlinename[10];
!   int i, c, qflag, pflag, status;
FILE*f = NULL;
pid_t   preproc = 0;
  
--- 1547,1556 
  #define WHITESP   " \t\f\v\n\r"
charbuf[BUFSIZ];
char*a, *p, *args[MAX_ARGS], *cmd = NULL;
!   charlinename[11];
!   int i = 0, c, qflag = 0, pflag = 0, status;
!   int lineno = 0;
!   char*file = NULL;
FILE*f = NULL;
pid_t   preproc = 0;
  
***
*** 1558,1613 
if ( s < 0 )
err(EX_UNAVAILABLE, "socket");
  
!   setbuf(stdout,0);
  
!   if (ac > 1 && access(av[ac - 1], R_OK) == 0) {
!   qflag = pflag = i = 0;
!   lineno = 0;
! 
!   while ((c = getopt(ac, av, "D:U:p:q")) != -1)
!   switch(c) {
!   case 'D':
!   if (!pflag)
!   errx(EX_USAGE, "-D requires -p");
!   if (i > MAX_ARGS - 2)
!   errx(EX_USAGE,
!"too many -D or -U options");
!   args[i++] = "-D";
!   args[i++] = optarg;
!   break;
  
!   case 'U':
!   if (!pflag)
!   errx(EX_USAGE, "-U requires -p");
!   if (i > MAX_ARGS - 2)
!   errx(EX_USAGE,
!"too many -D or -U options");
!   args[i++] = "-U";
!   args[i++] = optarg;
!   break;
  
!   case 'p':
!   pflag = 1;
!   cmd = optarg;
!   args[0] = cmd;
!   i = 1;
!   break;
  
!   case 'q':
!   qflag = 1;
!   break;
  
!   default:
!   show_usage(NULL);
!   }
  
!   av += optind;
!   ac -= optind;
!   if (ac != 1)
show_usage("extraneous filename arguments");
  
!   if ((f = fopen(av[0], "r")) == NULL)
!   err(EX_UNAVAILABLE, "fopen: %s", av[0]);
  
if (pflag) {
/* pipe through preprocessor (cpp or m4) */
--- 1558,1614 
if ( s < 0 )
err(EX_UNAVAILABLE, "socket");
  
!   setbuf(stdout, NULL);
  
!   while ((c = getopt(ac, av, "F:D:U:p:q")) != -1)
!   switch(c) {
!   case 'F':
!   if (file)
!   errx(EX_USAGE, "only one -F allowed");
!   file = optarg;
!   break;
  
!   case 'D':
!   if 

Re: how to start to be a hacker?

[G. Adam Stanislav]

On Sat, Jul 03, 1999 at 11:45:41AM -0600, Wes Peters wrote:
> And, in some cases, disasters averted.  I think all of us here have seen
> a few graphic examples lately of what happens when the mentoring process
> doesn't work.

Sadly, mentoring can occasionaly hurt the mentor, too.

I used to work for a company whose only programmer quit. They made
testing machines controlled by a computer. All of their software
was written in Turbo Pascal under MS DOS, and very poorly at that.

I was hired along with a young man who had just graduated from college.
The first thing I did was convince the boss to toss Turbo Pascal and
switch to a combination of C and assembly language.

The second thing I had to do was convince him not to fire the young
man. He majored in physics and had a few programming classes which
gave him the false impression he could program computers.

He was completely lost. The boss wanted to fire him because "we
don't run a charity here." I thought the young man was intelligent
and could learn. I helped him a lot, taught him many tricks. I
think I turned him into a fairly decent programmer (not a hacker,
mind you, because programming was a job to him, not a passion).

Two years later I was "laid off." The boss figured he no longer
needed both of us, and decided to keep the younger one because
he did not have to pay him as much as me.

The story had a happy ending after all: When the young man saw what
the boss did to me, within a few months he got a job with another
company and quit. So I think I did teach him well. :-)

> I think being a hacker is a combination of talent, ethics, and experience.

That's a good way of putting it.

> I've known talented and experienced programmers who weren't hackers,
> either because they didn't have the innate curiousity you mention or
> because they were ethically challenged and used their skills to steal,
> cheat, and destroy, which are *not* part of the hacker ethos.  Hackers
> create, crackers steal and destroy.

Agreed.

Adam


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Repalcement for grep(1)

[Jamie Howard]

I have used FreeBSD for a couple years now.  It is the only OS on my
desktop.  I have learnt many things from its source.  I felt it was time
to give something back.  A few minutes later I decided to offer it to all
BSDs.  I also will offer it to the DaemonLinux group, Apple, the  Darwin
group, and Tenon Systems, after public acceptence.  If there is anyone
else out there using a BSD base and GNU grep, they can have it too.

Looking aroud, I thought it would be great to try to replace one of the
GNU utilites included in the base with a version which is freely
redistributable.  I figured a compiler was beyond me, but a a couple of
the simpler utilities caught my eye.  Grep was first.

All of the code is original except for binary.c.  It is used with the -a
option to prevent searching binary files.  binary.c is extricated from
less-332's binary checking code.  I was just that lazy.

I made the version in FreeBSD 4.0 my target except for -A num, -B num, -C,
-num, and -Z.  These are not required by the Single Unix Specification or
POSIX and I felt they would bloat my code too significantly.  

I added the -o option from 4.4BSD-Lite2's implementation of egrep.  I also
stole it's man page.

One of the primary concerns was simplicity.  Looking through the code, you
should nobody should have any difficuly understanding the code.  Regex
does all the heavy work.  The object code is about 16% of the size of GNU 
grep.  I also do not use mmap(), I treat the file as a simple stream
instead.  My code is also a bit slower on larger files, but a bit faster
on smaller files.  Sometimes I am an order of magnitude slower.  I am
never that much faster.  I think not using mmap is the reason, but I do
not know for certain.

Now, I am having a problem though.  I cannot figure out how to implement
-w and -x.  For -x, I tried modifying the regular expression (foo) into
^(foo)$ before compiling, but that did not work.  I intended to do
something similar with -w.  Anyway, I am probably missing the obvious, but
does anyone have any ideas regarding how I should implement -w and -x?

If anyone can help with the -w and -x problems, would like to test, or has
any other comments, let me know.  I'd also like advice on the speed
issue.  Also, since I am at it, if you want anything added, lay it on me,
either code or ideas.  :)

The source code can be found at 

ftp://ftp.wam.umd.edu/pub/howardjp/grep-0.2.tar.gz

The source was written and tested on a FreeBSD 3.2 system.  I have also
compiled under BSDi 3.1.  It should work on any BSD and most any Unix.
The Makefile is written in the style of the rest of the FreeBSD utilites
so that it can be dropped right into /usr/src/usr.bin someday.  Only minor
modifications should be needed for BSDi, NetBSD, and OpenBSD.  I have not
built this on either NetBSD or OpenBSD but expect no problems.  If anyone
does have problems please let me know.  Fixes are even better. 

Thank you everyone, Jamie




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Porting LILO to FreeBSD

[Warner Losh]

In message <199907031912.maa01...@dingo.cdrom.com> Mike Smith writes:
: Neither; he'll have to tell the BIOS that the drive's not there.

That's what he's doing right now...  He doesn't want to keep doing
this since it is such a PITA.

However, other posters in the thread gave me enough hints that I think
that I can help him make it work.  LILO's trick of installing a small
translating shim on INT 13 may be just the ticket...

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Porting LILO to FreeBSD

[Mike Smith]

> In message <377cbe28.f3d4e...@cdsec.com> Graham Wheeler writes:
> : The only reason I even want to do this is that I still have a number
> : of old DOS games that won't work under Win95. And dosemu and Wine
> : just don't cut it either, unfortunately.
> 
> I have a friend that wants to boot FreeBSD on his IDE drive, or Win95
> on his SCSI drive.  No, it isn't an option to swap them, so the SCSI
> drive winds up being 'D'.  The only way he can boot Win95 is to
> completely disable the IDE drive from the BIOS' point of view :-(.
> 
> Would osbs solve this problem, or would he have to take a look at
> LILO?

Neither; he'll have to tell the BIOS that the drive's not there.

-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  msm...@freebsd.org
\\-- Joseph Merrick   \\  msm...@cdrom.com




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: bpfilter -> bpf patches [LONG]

[Dag-Erling Smorgrav]

Dag-Erling Smorgrav  writes:
> That said, thanks for asking - while looking into this matter I found
> another problem :) new patches will be available soon.

Nothing serious; a corrected patch is available on my freefall web
page (http://www.freebsd.org/~des/software/)

DES
-- 
Dag-Erling Smorgrav - d...@yes.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: mbufs question/problem

[Dennis]

At 04:10 PM 7/2/99 -0500, Stan Shkolnyy wrote:
>On Wed, 30 Jun 1999, Dennis wrote:
>
>>  
>> I have a customer who has been experiencing "slow downs" with a freebsd
>> routerthey have substantially increased performance by reducing
>> MINCLSIZE. I havent tracked the source, but im trying to hypothesize what
>> it might be. On the surface I cant see any relationship since very few
>> routines seem dependent on that value (m_devget() in particular, but I dont
>> believe they are using any driver that use it). Is it possible that they
>> are running out of small mbufs (they have NMBCLUSTERS set to a very high
>> value)?
>> 
>> Any ideas would be helpful.
>
>I have not noticed answers so far, so maybe their drivers copy mbufs very
>often. AFAIK, "small" mbufs are indeed copied but "cluster" ones are not, so
>when they forced the system to use more "cluster" mbufs, they got
>substantial savings on copy operations.

Well they are using Intel cards and our sync boards (of course our driver
is binary so the change wouldnt effect our driver), and I dont see the fxp
driver using small buffers. They are running bgp4...but I dont know what
kind of buffers are used for routes.

Dennis
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Login.conf (Whose problem is this) ?

[Gustavo V G C Rios]

i am trying to get a login classes for my users, so i decided to edit
/etc/login.conf.

Among other, i have yma classes this way:


shell:\
:maxproc=5:\
:tc=auth-default:


Looking for auth-default, i saw the following:

## Authentication methods
## Note that these are disabled by default, and libutil must
## be rebuilt with LOGIN_CAP_AUTH defined to use them.
#
#auth-defaults:\
#   :auth=krb_skey_or_passwd,passwd,kerberos,skey:
#
#auth-root-defaults:\
#   :auth-login=krb_skey_or_passwd,passwd,kerberos,skey:\
#   :auth-rlogin=krb_or_skey,kerberos,skey:
#
#auth-ftp-defaults:\
#   :auth=skey_or_pwd,passwd,skey:
#
#


Ok, so i need LOGIN_CAP_AUTH in libutil, i went to /usr/src/lib/libutil
and changed, Makefile:

From: 
#   @(#)Makefile8.1 (Berkeley) 6/4/93

LIB=util
SHLIB_MAJOR= 2
SHLIB_MINOR= 2
CFLAGS+=-Wall -DLIBC_SCCS -I${.CURDIR} -I${.CURDIR}/../../sys
#CFLAGS+=LOGIN_CAP_AUTH 

To:
#   @(#)Makefile8.1 (Berkeley) 6/4/93

LIB=util
SHLIB_MAJOR= 2
SHLIB_MINOR= 2
CFLAGS+=-Wall -DLIBC_SCCS -I${.CURDIR} -I${.CURDIR}/../../sys
CFLAGS+=LOGIN_CAP_AUTH 

Here came the problem:

myname# make
cc -O -pipe -Wall -DLIBC_SCCS -I/usr/src/lib/libutil
-I/usr/src/lib/libutil/../../sys LOGIN_CAP_AUTH -c
/usr/src/lib/libutil/login.c -o login.o
cc: LOGIN_CAP_AUTH: No such file or directory
*** Error code 1

Stop.


That's happened cause i turn on LOGIN_CAP_AUTH!
My doubt is: Shouldn't it be -DLOGIN_CAP_AUTH?

Is it right ? Can i use:

#   @(#)Makefile8.1 (Berkeley) 6/4/93

LIB=util
SHLIB_MAJOR= 2
SHLIB_MINOR= 2
CFLAGS+=-Wall -DLIBC_SCCS -I${.CURDIR} -I${.CURDIR}/../../sys
CFLAGS+=-DLOGIN_CAP_AUTH 


Is that a FreeBSD error or my one?


-- 
What about something different this year:
Crash your FreeBSD box!


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: bpfilter -> bpf patches [LONG]

[Brian F. Feldman]

On Sat, 3 Jul 1999, Doug wrote:

> Dag-Erling Smorgrav wrote:
> > 
> > [Bcc:ed to net, committers; please follow up on hackers]
> > 
> > Attached are patches for renaming 'pseudo-device bpfilter' to
> > 'peudo-device bpf', courtesy of glimpse(1) and ed(1). LINT and GENERIC
> > build fine with these patches; I haven't tried to run a kernel built
> > with them, though. Also, although I caught and corrected a few spacing
> > nits caused by chopping off five letters, there may be some I didn't
> > catch.
> > 
> > If no-one objects, I'll commit this to -CURRENT in a few days.
> 
>   Forgive me if this is a stupid question, but are there any circumstances
> where naming the kernel include file "bpf.h" would conflict with
> /usr/include/net/bpf.h? 
> 
>   In any case, this is a long overdue, and welcome change. Thank you. :)
> 
> Doug

How would that conflict? "bpf.h" is a local include, so it's not the same
include path set. Plus, it would only be included as  if -I/sys/net.

> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to start to be a hacker?

[Wes Peters]

"G. Adam Stanislav" wrote:
> 
> On Sat, Jul 03, 1999 at 01:18:52AM -0600, Wes Peters wrote:
> > > > You either are a hacker, or you are not. It is not something someone else
> > > > can teach you.
> > >
> > > This deserves a FAQ entry. What an awesome response.
> >
> > But it's certainly NOT something that you just are, either.  You have to
> > have talent, but you also have to have experience.  This is most often
> > done by a mentor.
> 
> If you have the innate curiosity mentioned in my message, you will obtain
> experience whether you have a mentor or not. Experience is best obtained
> by trying things. It cannot be imparted by anyone else (although, it can
> be encouraged).

And, in some cases, disasters averted.  I think all of us here have seen
a few graphic examples lately of what happens when the mentoring process
doesn't work.

I think being a hacker is a combination of talent, ethics, and experience.
I've known talented and experienced programmers who weren't hackers,
either because they didn't have the innate curiousity you mention or
because they were ethically challenged and used their skills to steal,
cheat, and destroy, which are *not* part of the hacker ethos.  Hackers
create, crackers steal and destroy.

But I'm certain you new that.  ;^)

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
http://softweyr.com/   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

USB floppy & booting

[Ollivier Robert]

Do we support booting from USB floppies ? I plan to buy one of the new VAIOs
(probably the Z505S with Celeron/333 + 64 MB + 12.1" screen) and it seems to
come with an USB floppy (as opposed to the probably-IDE of former models).

They've apparently ditched both the PS/2 mouse and the IDE floppy and moved to 
2x USB ports...
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May  9 20:16:32 CEST 1999



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Wes Peters]

"Brian F. Feldman" wrote:
> 
> On Sat, 3 Jul 1999, Jonathan Lemon wrote:
> 
> > On Jul 07, 1999 at 01:01:07AM -0400, Brian F. Feldman wrote:
> > > On Fri, 2 Jul 1999, Jonathan Lemon wrote:
> >
> > > > As for new code, use whichever you are comfortable with.  Personally, I
> > > > would recommend poll(), since it provides some added functionality over
> > > > select() that makes for easier programming.
> > >
> > > poll() is a huge pain to use, which is why I recommend select().
> >
> > Whichever you're comfortable with.  poll() isn't a pain once you know
> > how to use it, and it does bring additional benefits.
> 
> I don't see how you can not find poll() a pain when compared to select(). It
> requires so much set-up, much like (for instance) aio_write() as opposed to
> write(). I suppose if you're masochistic, you won't mind doing that :)

He wouldn't be a programmer unless masochistic.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
http://softweyr.com/   w...@softweyr.com


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: bpfilter -> bpf patches [LONG]

[Dag-Erling Smorgrav]

Doug  writes:
>   Forgive me if this is a stupid question, but are there any circumstances
> where naming the kernel include file "bpf.h" would conflict with
> /usr/include/net/bpf.h? 

I don't think so. The bpf.h created by config(8) resides in the
compile directory and is only used there; the "real" bpf.h is in
/sys/net/ (or /usr/include/net) and is only referred to as net/bpf.h.

Besides, if there were any confusion, I wouldn't (shouldn't) have been
able to build LINT and GENERIC with the patches.

That said, thanks for asking - while looking into this matter I found
another problem :) new patches will be available soon.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: BUG boot-time messages

[Brian F. Feldman]

On Sat, 3 Jul 1999, Jim Pazarena wrote:

> The following messages appear on the display as my FreeBSD machine is
> booting.
> 
> The spelling of "failed" is totally incorrect, and it would sure be
> nice to see the spelling corrected on a future release.

I don't see that in FreeBSD's HEAD, RELENG_2_2, or RELENG_3 branches.

> 
> To: p...@mail.qcislands.net
> Subject: BUG boot-time messages
> From: Charlie Root 
> Date: Sat, 3 Jul 1999 10:01:34 -0700
> --
> Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x330
> Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x334
> Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x230
> Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x234
> Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x130
> Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x134
>  ^^^
>   
>   
> --
> Jim Pazarena   mailto:p...@qcislands.net
>http://www.qcislands.net/paz
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

[PATCH] Preprocessor support for ipfw

[Ruslan Ermilov]

Hi!

There is one problem with ``preprocessor support for ipfw''.

relay# ls -l 100
ls: 100: No such file or directory
relay# ipfw list 100
00100 allow ip from any to any via lo0
relay# touch 100
relay# ipfw list 100
ipfw: error: extraneous filename arguments
[...]

Please review the attached patch.

Thanks,
-- 
Ruslan Ermilov  Sysadmin and DBA of the
r...@ucb.crimea.ua  United Commercial Bank,
r...@freebsd.orgFreeBSD committer,
+380.652.247.647Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age
Index: ipfw.8
===
RCS file: /usr/FreeBSD-CVS/src/sbin/ipfw/ipfw.8,v
retrieving revision 1.54
diff -c -r1.54 ipfw.8
*** ipfw.8  1999/06/19 18:43:18 1.54
--- ipfw.8  1999/07/03 17:35:18
***
*** 15,21 
  .Op Fl D Ar macro Ns Op Ns =value
  .Op Fl U Ar macro
  .Oc
! .Ar file
  .Nm ipfw
  .Oo
  .Fl f
--- 15,21 
  .Op Fl D Ar macro Ns Op Ns =value
  .Op Fl U Ar macro
  .Oc
! .Fl F Ar file
  .Nm ipfw
  .Oo
  .Fl f
Index: ipfw.c
===
RCS file: /usr/FreeBSD-CVS/src/sbin/ipfw/ipfw.c,v
retrieving revision 1.71
diff -c -r1.71 ipfw.c
*** ipfw.c  1999/06/19 18:43:15 1.71
--- ipfw.c  1999/07/03 17:35:18
***
*** 58,65 
  #include 
  #include 
  
- int   lineno = -1;
- 
  int   s;  /* main RAW socket */
  int   do_resolv=0;/* Would try to resolve all */
  int   do_acct=0;  /* Show packet/byte count  */
--- 58,63 
***
*** 1549,1556 
  #define WHITESP   " \t\f\v\n\r"
charbuf[BUFSIZ];
char*a, *p, *args[MAX_ARGS], *cmd = NULL;
!   charlinename[10];
!   int i, c, qflag, pflag, status;
FILE*f = NULL;
pid_t   preproc = 0;
  
--- 1547,1556 
  #define WHITESP   " \t\f\v\n\r"
charbuf[BUFSIZ];
char*a, *p, *args[MAX_ARGS], *cmd = NULL;
!   charlinename[11];
!   int i = 0, c, qflag = 0, pflag = 0, status;
!   int lineno = 0;
!   char*file = NULL;
FILE*f = NULL;
pid_t   preproc = 0;
  
***
*** 1558,1613 
if ( s < 0 )
err(EX_UNAVAILABLE, "socket");
  
!   setbuf(stdout,0);
  
!   if (ac > 1 && access(av[ac - 1], R_OK) == 0) {
!   qflag = pflag = i = 0;
!   lineno = 0;
! 
!   while ((c = getopt(ac, av, "D:U:p:q")) != -1)
!   switch(c) {
!   case 'D':
!   if (!pflag)
!   errx(EX_USAGE, "-D requires -p");
!   if (i > MAX_ARGS - 2)
!   errx(EX_USAGE,
!"too many -D or -U options");
!   args[i++] = "-D";
!   args[i++] = optarg;
!   break;
  
!   case 'U':
!   if (!pflag)
!   errx(EX_USAGE, "-U requires -p");
!   if (i > MAX_ARGS - 2)
!   errx(EX_USAGE,
!"too many -D or -U options");
!   args[i++] = "-U";
!   args[i++] = optarg;
!   break;
  
!   case 'p':
!   pflag = 1;
!   cmd = optarg;
!   args[0] = cmd;
!   i = 1;
!   break;
  
!   case 'q':
!   qflag = 1;
!   break;
  
!   default:
!   show_usage(NULL);
!   }
  
!   av += optind;
!   ac -= optind;
!   if (ac != 1)
show_usage("extraneous filename arguments");
  
!   if ((f = fopen(av[0], "r")) == NULL)
!   err(EX_UNAVAILABLE, "fopen: %s", av[0]);
  
if (pflag) {
/* pipe through preprocessor (cpp or m4) */
--- 1558,1614 
if ( s < 0 )
err(EX_UNAVAILABLE, "socket");
  
!   setbuf(stdout, NULL);
  
!   while ((c = getopt(ac, av, "F:D:U:p:q")) != -1)
!   switch(c) {
!   case 'F':
!   if (file)
!   errx(EX_USAGE, "only one -F allowed");
!   file = optarg;
!   break;
  
!   case 'D':
!   if

Re: bpfilter -> bpf patches [LONG]

[Brian F. Feldman]

On Sat, 3 Jul 1999, Doug wrote:

> Dag-Erling Smorgrav wrote:
> > 
> > [Bcc:ed to net, committers; please follow up on hackers]
> > 
> > Attached are patches for renaming 'pseudo-device bpfilter' to
> > 'peudo-device bpf', courtesy of glimpse(1) and ed(1). LINT and GENERIC
> > build fine with these patches; I haven't tried to run a kernel built
> > with them, though. Also, although I caught and corrected a few spacing
> > nits caused by chopping off five letters, there may be some I didn't
> > catch.
> > 
> > If no-one objects, I'll commit this to -CURRENT in a few days.
> 
>   Forgive me if this is a stupid question, but are there any circumstances
> where naming the kernel include file "bpf.h" would conflict with
> /usr/include/net/bpf.h? 
> 
>   In any case, this is a long overdue, and welcome change. Thank you. :)
> 
> Doug

How would that conflict? "bpf.h" is a local include, so it's not the same
include path set. Plus, it would only be included as  if -I/sys/net.

> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: bpfilter -> bpf patches [LONG]

[Doug]

Dag-Erling Smorgrav wrote:
> 
> [Bcc:ed to net, committers; please follow up on hackers]
> 
> Attached are patches for renaming 'pseudo-device bpfilter' to
> 'peudo-device bpf', courtesy of glimpse(1) and ed(1). LINT and GENERIC
> build fine with these patches; I haven't tried to run a kernel built
> with them, though. Also, although I caught and corrected a few spacing
> nits caused by chopping off five letters, there may be some I didn't
> catch.
> 
> If no-one objects, I'll commit this to -CURRENT in a few days.

Forgive me if this is a stupid question, but are there any circumstances
where naming the kernel include file "bpf.h" would conflict with
/usr/include/net/bpf.h? 

In any case, this is a long overdue, and welcome change. Thank you. :)

Doug


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

BUG boot-time messages

[Jim Pazarena]

The following messages appear on the display as my FreeBSD machine is
booting.

The spelling of "failed" is totally incorrect, and it would sure be
nice to see the spelling corrected on a future release.

To: [EMAIL PROTECTED]
Subject: BUG boot-time messages
From: Charlie Root <[EMAIL PROTECTED]>
Date: Sat, 3 Jul 1999 10:01:34 -0700
--
Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x330
Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x334
Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x230
Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x234
Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x130
Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x134
 ^^^

--
Jim Pazarena   mailto:[EMAIL PROTECTED]
   http://www.qcislands.net/paz



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to start to be a hacker?

[Wes Peters]

"G. Adam Stanislav" wrote:
> 
> On Sat, Jul 03, 1999 at 01:18:52AM -0600, Wes Peters wrote:
> > > > You either are a hacker, or you are not. It is not something someone 
> > > > else
> > > > can teach you.
> > >
> > > This deserves a FAQ entry. What an awesome response.
> >
> > But it's certainly NOT something that you just are, either.  You have to
> > have talent, but you also have to have experience.  This is most often
> > done by a mentor.
> 
> If you have the innate curiosity mentioned in my message, you will obtain
> experience whether you have a mentor or not. Experience is best obtained
> by trying things. It cannot be imparted by anyone else (although, it can
> be encouraged).

And, in some cases, disasters averted.  I think all of us here have seen
a few graphic examples lately of what happens when the mentoring process
doesn't work.

I think being a hacker is a combination of talent, ethics, and experience.
I've known talented and experienced programmers who weren't hackers,
either because they didn't have the innate curiousity you mention or
because they were ethically challenged and used their skills to steal,
cheat, and destroy, which are *not* part of the hacker ethos.  Hackers
create, crackers steal and destroy.

But I'm certain you new that.  ;^)

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
http://softweyr.com/   w...@softweyr.com


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: mbufs question/problem

[Dennis]

At 04:10 PM 7/2/99 -0500, Stan Shkolnyy wrote:
>On Wed, 30 Jun 1999, Dennis wrote:
>
>>  
>> I have a customer who has been experiencing "slow downs" with a freebsd
>> routerthey have substantially increased performance by reducing
>> MINCLSIZE. I havent tracked the source, but im trying to hypothesize what
>> it might be. On the surface I cant see any relationship since very few
>> routines seem dependent on that value (m_devget() in particular, but I dont
>> believe they are using any driver that use it). Is it possible that they
>> are running out of small mbufs (they have NMBCLUSTERS set to a very high
>> value)?
>> 
>> Any ideas would be helpful.
>
>I have not noticed answers so far, so maybe their drivers copy mbufs very
>often. AFAIK, "small" mbufs are indeed copied but "cluster" ones are not, so
>when they forced the system to use more "cluster" mbufs, they got
>substantial savings on copy operations.

Well they are using Intel cards and our sync boards (of course our driver
is binary so the change wouldnt effect our driver), and I dont see the fxp
driver using small buffers. They are running bgp4...but I dont know what
kind of buffers are used for routes.

Dennis
> 


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

USB floppy & booting

[Ollivier Robert]

Do we support booting from USB floppies ? I plan to buy one of the new VAIOs
(probably the Z505S with Celeron/333 + 64 MB + 12.1" screen) and it seems to
come with an USB floppy (as opposed to the probably-IDE of former models).

They've apparently ditched both the PS/2 mouse and the IDE floppy and moved to 
2x USB ports...
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr
FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May  9 20:16:32 CEST 1999



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: bpfilter -> bpf patches [LONG]

[Doug]

Dag-Erling Smorgrav wrote:
> 
> [Bcc:ed to net, committers; please follow up on hackers]
> 
> Attached are patches for renaming 'pseudo-device bpfilter' to
> 'peudo-device bpf', courtesy of glimpse(1) and ed(1). LINT and GENERIC
> build fine with these patches; I haven't tried to run a kernel built
> with them, though. Also, although I caught and corrected a few spacing
> nits caused by chopping off five letters, there may be some I didn't
> catch.
> 
> If no-one objects, I'll commit this to -CURRENT in a few days.

Forgive me if this is a stupid question, but are there any circumstances
where naming the kernel include file "bpf.h" would conflict with
/usr/include/net/bpf.h? 

In any case, this is a long overdue, and welcome change. Thank you. :)

Doug


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

BUG boot-time messages

[Jim Pazarena]

The following messages appear on the display as my FreeBSD machine is
booting.

The spelling of "failed" is totally incorrect, and it would sure be
nice to see the spelling corrected on a future release.

To: p...@mail.qcislands.net
Subject: BUG boot-time messages
From: Charlie Root 
Date: Sat, 3 Jul 1999 10:01:34 -0700
--
Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x330
Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x334
Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x230
Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x234
Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x130
Jul  3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x134
 ^^^

--
Jim Pazarena   mailto:p...@qcislands.net
   http://www.qcislands.net/paz



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to start to be a hacker?

[G. Adam Stanislav]

On Sat, Jul 03, 1999 at 01:18:52AM -0600, Wes Peters wrote:
> > > You either are a hacker, or you are not. It is not something someone else
> > > can teach you.
> > 
> > This deserves a FAQ entry. What an awesome response.
> 
> But it's certainly NOT something that you just are, either.  You have to
> have talent, but you also have to have experience.  This is most often
> done by a mentor.

If you have the innate curiosity mentioned in my message, you will obtain
experience whether you have a mentor or not. Experience is best obtained
by trying things. It cannot be imparted by anyone else (although, it can
be encouraged).

Adam


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to start to be a hacker?

[G. Adam Stanislav]

On Sat, Jul 03, 1999 at 01:18:52AM -0600, Wes Peters wrote:
> > > You either are a hacker, or you are not. It is not something someone else
> > > can teach you.
> > 
> > This deserves a FAQ entry. What an awesome response.
> 
> But it's certainly NOT something that you just are, either.  You have to
> have talent, but you also have to have experience.  This is most often
> done by a mentor.

If you have the innate curiosity mentioned in my message, you will obtain
experience whether you have a mentor or not. Experience is best obtained
by trying things. It cannot be imparted by anyone else (although, it can
be encouraged).

Adam


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: support for i386 hardware debug watch points

[Brian F. Feldman]

On Sat, 3 Jul 1999, Peter Wemm wrote:

> Thomas David Rivers wrote:
> > > 
> > > Is there any interest in supporting something like this in FreeBSD?
> > > I'm volunteering to spend some cycles on this, but I don't want to go
> > > to the effort if there's little chance that the work would be
> > > integrated.
> > > 
> > > Thanks,
> > > -Brian
> > > -- 
> > > Brian DeanSAS Institute Inc   [EMAIL PROTECTED]
> > > 
> > 
> > 
> >  Brian -
> > 
> >Scan through the mail archives - I brought this up about this
> >  time last year, I think...
> > 
> >There were several responses - some people may be willing to
> >  assist...
> 
> I'll chime in..  I'd be quite willing to bring something like this in,
> assuming it was done reasonably cleanly.  It shouldn't be too hard to do it
> without imparing portability across cpu/arch types.
> 
> I think this would be quite useful, especially if gdb could be made aware
> of it too.

I think this would be great too, but I have a concern. Not all CPUs (x86)
support this; make ABSOLUTELY sure it doesn't do this kind of thing on
hardware which doesn't support it, please!

> 
> > - Dave Rivers -
> 
> Cheers,
> -Peter
> --
> Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: support for i386 hardware debug watch points

[Brian F. Feldman]

On Sat, 3 Jul 1999, Peter Wemm wrote:

> Thomas David Rivers wrote:
> > > 
> > > Is there any interest in supporting something like this in FreeBSD?
> > > I'm volunteering to spend some cycles on this, but I don't want to go
> > > to the effort if there's little chance that the work would be
> > > integrated.
> > > 
> > > Thanks,
> > > -Brian
> > > -- 
> > > Brian DeanSAS Institute Inc   brd...@unx.sas.com
> > > 
> > 
> > 
> >  Brian -
> > 
> >Scan through the mail archives - I brought this up about this
> >  time last year, I think...
> > 
> >There were several responses - some people may be willing to
> >  assist...
> 
> I'll chime in..  I'd be quite willing to bring something like this in,
> assuming it was done reasonably cleanly.  It shouldn't be too hard to do it
> without imparing portability across cpu/arch types.
> 
> I think this would be quite useful, especially if gdb could be made aware
> of it too.

I think this would be great too, but I have a concern. Not all CPUs (x86)
support this; make ABSOLUTELY sure it doesn't do this kind of thing on
hardware which doesn't support it, please!

> 
> > - Dave Rivers -
> 
> Cheers,
> -Peter
> --
> Peter Wemm - pe...@freebsd.org; pe...@yahoo-inc.com; pe...@netplex.com.au
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Alfred Perlstein]

On Sat, 3 Jul 1999, Jonathan Lemon wrote:

> On Jul 07, 1999 at 11:27:57AM -0400, Brian F. Feldman wrote:
> > On Sat, 3 Jul 1999, Jonathan Lemon wrote:
> > 
> > > On Jul 07, 1999 at 01:01:07AM -0400, Brian F. Feldman wrote:
> > > > On Fri, 2 Jul 1999, Jonathan Lemon wrote:
> > > 
> > > > > As for new code, use whichever you are comfortable with.  Personally, I
> > > > > would recommend poll(), since it provides some added functionality over
> > > > > select() that makes for easier programming.
> > > > 
> > > > poll() is a huge pain to use, which is why I recommend select().
> > > 
> > > Whichever you're comfortable with.  poll() isn't a pain once you know
> > > how to use it, and it does bring additional benefits.
> > 
> > I don't see how you can not find poll() a pain when compared to select(). It
> > requires so much set-up, much like (for instance) aio_write() as opposed to
> > write(). I suppose if you're masochistic, you won't mind doing that :)
> 
> Yes, it does require more initial setup.  But consider:
> 
> - you don't have to re-initialize the fd sets every time around the
>   loop, as you do with select().  This administrative overhead is 
>   moved into the initial setup, not into the main loop.
> 
> - it becomes simple to ignore a slot entry; simply set the fd value to -1.
> 
> - you get notification when the fd is closed.  E.g.: you can poll()
>   on a fd, ignoring both read ready and write ready state, and get
>   POLLHUP returned when it closes.  for select(), the only way to
>   know that the fd closed is to actually do a read() on the descriptor,
>   and have it return EOF.

I agree.

With a proper algorithm you can also track the fds in use and 
migrate them to lower slots in the pollfd array as well as make
an allocator that attempts to grab slots at the beginning.

Just something i'm working on right now :)

-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] 
systems administrator and programmer
Win Telecom - http://www.wintelcom.net/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: poll() vs select()

[Alfred Perlstein]

On Sat, 3 Jul 1999, Jonathan Lemon wrote:

> On Jul 07, 1999 at 11:27:57AM -0400, Brian F. Feldman wrote:
> > On Sat, 3 Jul 1999, Jonathan Lemon wrote:
> > 
> > > On Jul 07, 1999 at 01:01:07AM -0400, Brian F. Feldman wrote:
> > > > On Fri, 2 Jul 1999, Jonathan Lemon wrote:
> > > 
> > > > > As for new code, use whichever you are comfortable with.  Personally, 
> > > > > I
> > > > > would recommend poll(), since it provides some added functionality 
> > > > > over
> > > > > select() that makes for easier programming.
> > > > 
> > > > poll() is a huge pain to use, which is why I recommend select().
> > > 
> > > Whichever you're comfortable with.  poll() isn't a pain once you know
> > > how to use it, and it does bring additional benefits.
> > 
> > I don't see how you can not find poll() a pain when compared to select(). It
> > requires so much set-up, much like (for instance) aio_write() as opposed to
> > write(). I suppose if you're masochistic, you won't mind doing that :)
> 
> Yes, it does require more initial setup.  But consider:
> 
> - you don't have to re-initialize the fd sets every time around the
>   loop, as you do with select().  This administrative overhead is 
>   moved into the initial setup, not into the main loop.
> 
> - it becomes simple to ignore a slot entry; simply set the fd value to -1.
> 
> - you get notification when the fd is closed.  E.g.: you can poll()
>   on a fd, ignoring both read ready and write ready state, and get
>   POLLHUP returned when it closes.  for select(), the only way to
>   know that the fd closed is to actually do a read() on the descriptor,
>   and have it return EOF.

I agree.

With a proper algorithm you can also track the fds in use and 
migrate them to lower slots in the pollfd array as well as make
an allocator that attempts to grab slots at the beginning.

Just something i'm working on right now :)

-Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] 
systems administrator and programmer
Win Telecom - http://www.wintelcom.net/



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message