Re: [CFR] IPv6 support for pserver of cvs

[Jeroen Ruigrok/Asmodai]

-On [20011104 15:28], Hajimu UMEMOTO ([EMAIL PROTECTED]) wrote:
>I wish to add IPv6 support to pserver of cvs.  You can find the patch
>from:
>
>   http://www.imasy.or.jp/?(J?ume/ipv6/FreeBSD/cvs-ipv6.diff
>
>This patch is based on the patch by KAME folks.  But, the patch is for
>1.11 and isn't applied cleanly to our cvs.  So, some additional
>modification was made.

Please feed this to the cvshome.org guys, that way we can just import
the new version along the vendorbranch.

-- 
Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org]
Documentation nutter/C-rated Coder, finger [EMAIL PROTECTED]
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/
Those who cannot remember the past are condemned to repeat it...


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

Re: gif(4) question

[Jeroen Ruigrok/Asmodai]

[This question is more appropriate for -net IMHO]

-On [20010322 03:00], David E. Cross ([EMAIL PROTECTED]) wrote:
>I recently tried (for the first time) to get gif running under FreeBSD
>4.3-BETA (cvsup-ed yesterday).  I noticed the following:
>
>gifconfig gif0 inet 10.1.1.1 10.1.2.1
>ifconfig gif0 192.168.1.1 192.168.1.2 netmask 0xff00
>
>and then I 'ping 192.168.1.1' it will try to route the packet instead of 
>reply directly.  I need to 'route add 192.168.1.1 127.0.0.1' to have it
>reply to the packet directly.  I don't need to do this for other types
>of interfaces... did I mess something up, is this how it is supposed to 
>be (doesn't seem to be documented as such).

I think that's how it is supposed to be given that gif's main function
is to tunnel things and it works on a point-to-point basis.

I might be wrong, in which case I am sure UMEMOTO-san or ITOJUN-san will
correct me.

-- 
Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
What is to be, will be.  And what isn't to be sometimes happens...

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

Re: Debuging kernel crashes

[Jeroen Ruigrok/Asmodai]

[moved to hackers, since it is more appropriate there than in -net]
[net bcc:'d]

-On [20010320 07:00], Gurpratap Virdi ([EMAIL PROTECTED]) wrote:
>I modified the FreeBSD 4.2 kernel and occasionally the kernel crashes. How
>can I determine the line of code that caused the crash? I tried addr2line
>with the fault address but that didn't work. Thanks in advance!!

Please see http://www.freebsd.org/handbook/kerneldebug.html

If you find any problems with that let us know in -doc and we'll fix the
docs.

-- 
Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
Sweet taste of vindication, It turns to ashes in your mouth...

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

Re: if_fxp - the real point

[Jeroen Ruigrok/Asmodai]

-On [20010314 17:38], Dennis ([EMAIL PROTECTED]) wrote:
>At 06:35 AM 03/14/2001, Jeroen Ruigrok/Asmodai wrote:
>
>>That's what Soeren and me did.  HighPoint was very forthcoming with
>>documentation and as part of that synergy they put the FreeBSD Hardware
>>logo on their frontpage <http://www.highpoint-tech.com> and us
>>mentioning it on our webpages as well as being a primary recommendation
>>over other vendors back when we got little information out of other
>>vendors.
>
>I'm sure that High-point's competitors are shivering in their boots over 
>this powerful alliance.

Well Dennis,

I congratulate you.  Be assured that with this attitude you just
displayed you made me decide never to recommend ET Inc., for any of my
present and future projects.

-- 
Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
If dreams are like movies, then memories are films about ghosts...

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

Re: if_fxp - the real point

[Jeroen Ruigrok/Asmodai]

-On [20010310 01:00], Lyndon Nerenberg ([EMAIL PROTECTED]) wrote:
>Perhaps a first step towards leaning on the vendors for documentation
>is to publically declare our support for those vendors who *do*
>release documentation under reasonable terms. One way to do this
>is to acknowledge those vendors in the hardware section of the
>handbook, and encourage people to support them by buying thier
>products.

That's what Soeren and me did.  HighPoint was very forthcoming with
documentation and as part of that synergy they put the FreeBSD Hardware
logo on their frontpage  and us
mentioning it on our webpages as well as being a primary recommendation
over other vendors back when we got little information out of other
vendors.

-- 
Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
What is history but a fable agreed 'pon?

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

Re: Cvsup and ports

[Jeroen Ruigrok/Asmodai]

-On [20010220 02:30], Nigel Taylor ([EMAIL PROTECTED]) wrote:
>I recently did a CVSUP on my ports because i wanted to install
>enlightenment did a make install and recieved the following error.
>
>Error: your port uses an old layout. Please update it to match this
>bsd.port.mk. If you have updated your ports collection via cvsup and
>are still getting this error, see Q12 and Q13 in the cvsup FAQ ob
>http://www.polstra.com for further information.

Please ask questions like this on the freebsd-questions mailinglist.

>Now i have done everything it has said, still get the same error

You obviously missed to do something. :)

Either:

1) make world

2) cd /usr/src/share/mk [after updating it]; make install

And that should fix things.

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
I'm a child of the air, I'm a witch of the wind...


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

Re: soft updates and qmail (RE: qmail IO problems)

[Jeroen Ruigrok/Asmodai]

-On [20010206 20:25], Andre Oppermann ([EMAIL PROTECTED]) wrote:
>> ... provided that qmail calls fsync(2).
>
>$ cd qmail-ldap/
>$ grep fsync * | wc -l
>  21

Of course that says nothing if the fsync()'s are not placed at strategic
places.

fsync();
fsync();
fsync();
.
.
.
fsync();

And _then_ the disk manipulation routines/functions won't do much good
off course.

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
May you get - not what you deserve - but your heart's desire...


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

Re: style(9)

[Jeroen Ruigrok/Asmodai]

-On [2701 09:25], Wes Peters ([EMAIL PROTECTED]) wrote:
>
>Or simply get a wider editor.  Seriously.  Writing code in 80 columns is
>an anachronism.

Tastes do differ for that.

Often the 80 column boundary reminds me not to use
functions_which_have_crazy_long_names_with_underscores(), but be a
little more brief, but not too. ;)

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
Here's a mirror, there's a screen, on both ways you can get in...


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

Re: style(9)

[Jeroen Ruigrok/Asmodai]

-On [2630 19:34], Warner Losh ([EMAIL PROTECTED]) wrote:
>
>I personally like 4 myself, but let's not get into a stupid tab width
>war were people argue about values from 2 to 6 that ends in the
>resolution that 8 might not be right, but reformatting everything
>would suck too bad to change it and introducing new code that isn't
>formatted at 8 would be confusing.  OK?  We've done that before.

For more wisdom on that read NetBSD-kernel and NetBSD-misc archives of
this year, february IIRC.

They just went through the whole debate.

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
An expert is one who knows more and more about less and less...


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

Re: Invalidating PACK!!!

[Jeroen Ruigrok/Asmodai]

-On [2701 11:18], Mustafa Deeb ([EMAIL PROTECTED]) wrote:
>(da2:ahc0:0:4:0): Invalidating pack
>(da2:ahc0:0:4:0): Invalidating pack
>(da2:ahc0:0:4:0): Invalidating pack
>(da2:ahc0:0:4:0): SCB 0x62 - timed out while idle, SEQADDR == 0xb
>(da2:ahc0:0:4:0): Queuing a BDR SCB
>(da2:ahc0:0:4:0): no longer in timeout, status = 34a

Last times it happened to me it was either:

- bad cabling

- faulty HD/firmware

- system ran way too hot

I haven't really had a chance to blame the SCSI subsystem present in
FreeBSD and trust me, I have had my share of these messages.

Hope this helps,

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
And the price of a Memory is the Memory of the Sorrow it brings...


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

Re: Fwd: socket.h and _POSIX_SOURCE

[Jeroen Ruigrok/Asmodai]

-On [2425 20:08], Arun Sharma ([EMAIL PROTECTED]) wrote:
>Would it be fair to say this is a (POSIX non-compliance) bug in the
>header files ?

As Bruce Evans was kind enough to reassure me:

sys/socket.h is not a POSIX header.

'nuff said I guess.

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
Who looks under the surface does so at his own risk...


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

Re: Fwd: socket.h and _POSIX_SOURCE

[Jeroen Ruigrok/Asmodai]

-On [2420 20:02], Arun Sharma ([EMAIL PROTECTED]) wrote:
>Comments ?
>
>$ cat test.c
>#include 
>#include 
>$ cc -D_POSIX_SOURCE -c test.c
>In file included from test.c:2:
>/usr/include/sys/socket.h:47: syntax error before `sa_family_t'
>/usr/include/sys/socket.h:47: warning: data definition has no type or storage
>  class

sys/socket.h declares sa_family_t as a u_char.

If we look at sys/types.h we see:

#ifndef _POSIX_SOURCE
typedef unsigned char   u_char;
[snip]
#endif

Which combined with D_POSIX_SOURCE causes [logical] problems.

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
Who looks under the surface does so at his own risk...


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

Re: Shim Code #error needed

[Jeroen Ruigrok/Asmodai]

-On [2326 00:00], Warner Losh ([EMAIL PROTECTED]) wrote:
>
>However, I was thinking that it would be nice if there was something
>simple to grep for to see what drivers still needed to be converted.

I assume you mean PCI devices, since ISA are detailed in:

/src/sys/i386/isa/isa_compat.h

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
The descent to hell is easy...


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

Re: Is FreeBSD dead? Well, not in theory...

[Jeroen Ruigrok/Asmodai]

-On [2312 00:00], Joe Abley ([EMAIL PROTECTED]) wrote:
>On Sat, Mar 11, 2000 at 01:36:31PM -0500, Dennis wrote:

>> Another point is that Open Source is virtually synonomous with "Totally
>> undocumented".
>
>This is sillier.

Exactly, and it also slightly pisses me off...

Then I guess I wrote all the manpages and documents for nothing.

elf.5 comes to mind for a very handy resource.

http://home.wxs.nl/~asmodai/newbus-draft.txt comes to mind.  And when
that is finished the manpages will follow.

That's also why I am wasting my time slowly documenting the FreeBSD
internals in my spare time.

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
You prayed before, who are the prayers for..?


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

WRT `Is FreeBSD dead?'

[Jeroen Ruigrok/Asmodai]

Could we place relocate this topic to -chat or -advocacy, since it
doesn't seem that correct to be discussed on -hackers.

Hackers was meant for quality technical discussion, not discussions
about FUD, stupidity of people whom don't read official messages posted
prior to stating things, spinning off and more of that non-technical
crap.

Thanks,

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
I must be cruel, only to be kind...


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

Re: yamaha japan relationships anyone?

[Jeroen Ruigrok/Asmodai]

-On [2221 08:00], Daniel C. Sobral ([EMAIL PROTECTED]) wrote:
>No, it was wrt to Playstation, Nintendo, Sega or something like that.
>M... I thinking it was probably wrt to SEGA, because there was also
>a trademark dispute related to a small string. :-) An american company
>tried to get a license to distribute games for the game console, but the
>japanese company only licensed under the terms "We'll hold exclusive
>distribution rights to all games you produce", which was deemed
>unacceptable. So, the company went ahead and did a straight clean-room
>reverse engineering. They were later sued for the following (roughly):

This sounds like the URL I paste in the channel which was a case of
SEGA versus Electronic Arts IIRC.

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
Religion... Is the opium of the people...


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

Re: yamaha japan relationships anyone?

[Jeroen Ruigrok/Asmodai]

-On [2220 14:14], Doug Rabson ([EMAIL PROTECTED]) wrote:
>On Sun, 20 Feb 2000, Karsten W. Rohrbach wrote:
>
>> i just messaged the guys from yamaha japan for specs on their pci audio
>> chipsets to get some decent documentation to start torturing those ymf744
>> soundcards. no response. i mailed again. same result. do they actually
>> read their mail or is this an uncommon thing in .jp?
>
>I have had more-or-less the same experience. I did get a response which
>completely misunderstood what I was asking and assumed I wanted the
>source code to their windows driver. My reply explaining that I really
>just wanted documentation went unanswered. Sigh.

Well Doug,

you're in the UK, so part of the European Community.

And since you requested information from Yamaha and got none, you are
now legally clean of action due to the law that you may
disassemble/reverse engineer their drivers to obtain the information you
need to program the driver.

For once, a cool law in Europe.

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
Religion... Is the opium of the people...


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

Re: IPFW / IP Filter question

[Jeroen Ruigrok/Asmodai]

-On [2203 22:43], [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
>I would have thought you would use the tee option in ipfw for this, but
>its not implemented yet according to my man pages, so I was wondering if
>there was another way to do this, cause it makes traffic analysis a hell
>of a lot easier if I can do this rather than having to sniff it with bpf
>or something.

Didn't CURRENT add the tee option by now?

I really recall a commit message stating tee support has been added...

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
The Eyes of Truth are always watching you...


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

Re: Broken pipe

[Jeroen Ruigrok/Asmodai]

[This does _not_ belong on hackers, follow-ups set to questions]

-On [2206 04:00], Alex ([EMAIL PROTECTED]) wrote:
>
>When I run my script,sometimes I receive next 
>message:
>
>"/usr/sbin/wanrouter: line 5 288 Broken pipe
>ls $ROUTER_LOCK_DIR/   289 Exit 1 | grep -q 
>wanpipe*"

Ehm, the above looks kinda weird and would most certainly explain the
broken pipe.  A broken pipe is when stdout had a connection to the
stdin of the next program but the pipe got severed somehow (or never got
set up in the first place).

>I use bash-2.03 shell.
>The line is cause to this message is :
>
>ls $ROUTER_LOCK_DIR/ | grep -q wanpipe* && rm 
>$ROUTER_LOCK_DIR/*

And this does work from the command line?  It looks ok to me.

-- 
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
There is no greater sorrow than to recall, in misery, the time when we
were happy...


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

Re: How to write a device-driver?

[Jeroen Ruigrok/Asmodai]

-On [2124 00:00], Joachim Jäckel ([EMAIL PROTECTED]) wrote:
>
>Here´s some information to the card I'd like to support:
>
>It's a Miro DC10+ Video Grabber Card for Non-Linear Video-Editing.
>It uses a Siemens SAA7110, a Zoran 36060+36067 and a ADV chip to en-
>and decode the video-information. I got the specifications for the chips
>from Siemens and Zoran's Web-Sites and a first driver-skeleton was
>generated through the /usr/share/examples/drivers/make_pci... script for
>me.

Did you contact Miro?

And /usr/share/examples/drivers/make_pci is pre 4.0.

>Currently I get a boot-message from my kernel, that he has found the
>card.(I read the pci_id and send a text-message :-)

That's a good start.

>Additionally I found a linux-driver for this card (an early one...) but
>it is not fully compatible with the documentation, I got.

It can make certain things clear.

>Maybe you would allow me one question? (To get a little faster to the
>information than browsing through the source.)

Asking questions is free. =)

>But how get's the zoran36067_regs structure the information from the
>chip?

If you were using newbus (on FreeBSD 4.0) I'd say bus_space_read_#() to
get the info in the registers our of your chip.

>If I change the content of the structure, which function would change
>the registers on the chip accordingly? (Or is it done through the call
>of pci_map_mem? And is everything I change to the structure
>automatically changed on the card?)

I have to show my lack of 2.2.x and 3.x driver programming.  I am
spoiled due to 4.x.  I think someone else needs to answer this.  Juergen
appears to know 3.x driver programming.

>Sorry, if these questions are real dumb ones!

Not at all.

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
How the gods kill...


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

Re: Learning the FreeBSD Kernel

[Jeroen Ruigrok/Asmodai]

-On [2124 19:55], Warner Losh ([EMAIL PROTECTED]) wrote:
>In message <[EMAIL PROTECTED]> Jeroen Ruigrok/Asmodai 
>writes:
>: >As long as a device is just inb/outb (I seem to recall newbus have a
>: >replacement for these)
>: 
>: bus_space_read_#() / bus_space_write_#()
>: 
>: Where # is 1, 2, 4, or 8.  But I don't think we support atomic 8 byte
>: atomic reads and writes.
>
>It isn't so much that "we" don't support atomic 8 byte operations, it
>is that the busses and cpus don't support these operations...

Sorry, mea culpa.  It's just that I have been shifting back and forth
between NetBSD and FreeBSD and that I see they have
bus_space_[read|write]_8 defined and we don't.

So my statement was actually more in reflection to NetBSD's support of
it.  Whether or not they support busses which do 8 byte atomic
reads/writes I am not sure of.

Thanks for the reality adjustment Warner. =)

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Woe to the vanquished!


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

Re: Learning the FreeBSD Kernel

[Jeroen Ruigrok/Asmodai]

-On [2124 08:01], Chuck Robey ([EMAIL PROTECTED]) wrote:
>
>The problem is, you can't even find what the interfaces are.  Reading the
>code isn't very useful if you can't even find the right place to start
>from.  At least the interface points could be listed, so that someone
>would know where to begin.

Working on that.

And I am finally getting somewhere.  I hope to commit some manpages,
very rough for now, somewhere this week.

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
We've laid together in the sun before the mind-rape has begun...


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

Re: Learning the FreeBSD Kernel

[Jeroen Ruigrok/Asmodai]

-On [2124 10:13], William A. Maniatty ([EMAIL PROTECTED]) wrote:

>Is it possible to get a look at the digital Unix guides, that might be a
>good starting point.  Are they on line (perhaps you have a URL)?

http://www.unix.digital.com/faqs/publications/dev_doc/DOCUMENTATION/HTML/Digital_UNIX_Bookshelf.html

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
But Time, keeps flowing like a river (on and on)...


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

Re: Learning the FreeBSD Kernel

[Jeroen Ruigrok/Asmodai]

-On [2124 10:13], Daniel C. Sobral ([EMAIL PROTECTED]) wrote:

>As long as a device is just inb/outb (I seem to recall newbus have a
>replacement for these)

bus_space_read_#() / bus_space_write_#()

Where # is 1, 2, 4, or 8.  But I don't think we support atomic 8 byte
atomic reads and writes.

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
When we have not what we like, we must like what we have...


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

Re: Learning the FreeBSD Kernel

[Jeroen Ruigrok/Asmodai]

-On [2124 10:13], Daniel C. Sobral ([EMAIL PROTECTED]) wrote:
>Bill Maniatty wrote:
>> 
>> First we want to get the mechanism of driver installation down, then
>> try our hands at writing our own driver.  I fear that if we roll our own
>> driver software we may find that if we have errors (not that we ever have
>> errors mind you :-) we may not be able to isolate the cause.  This is
>> why I was leaning towards reinstalling a working driver first.
>
>You won't have any trouble at all with basic driver installation. In
>fact, this is driver skeleton, that can be templated (and used to... but
>I don't know if we have newbus templates or not).

man 9 driver.

>Notice that most developers use kld to develop their drivers. Not having
>to recompile the kernel and reboot really helps. :-) There exists one
>tutorial-style guide to writing kld's. It's a "hacking" guide to the use
>of kld's as a way to introduce back-doors in FreeBSD, and though it's
>somewhat "unclean" wrt to interface description, it's an effective
>tutorial. I'm sure it can be found from FreeBSD's web site.

Trust me, writing modules is the _least_ of your worries.  If I can
write a module then every^H^H^H^H^Hcluefull people can. =)

/usr/src/sys/modules

>As a next step, I suggest writing "virtual" drivers, not bound to any
>hardware. There are many such drivers in the tree. As a trivial example,
>and a favorite of many, the screen savers.
>
>The above will get you proficient with the basics of writing device
>drivers, but still leave a lot out. Let's see...

[Not looking at the source code for those I dare say:] But they are not
using any busspace/newbus functionality for all I know.  And cannot be
compared to the `real' drivers IMHO.

>> How mature is the USB driver technology?  If it is pretty preliminary
>> we may wish to visit that later.  Please recall that we are on a learning
>> curve here.
>
>If we support ethernet cards on USB, I'd say it's pretty mature. :-)
>
>Anyway, here is what virtual drivers won't teach: how to get resources,
>which will vary from bus to bus, how to interact with some of the kernel
>subsystems... How does one write a tun device? How does one write a
>network device? How does one write a network protocol? How does one
>write a CAM device (more than one type exist -- some virtual and some
>not)? How does one write a bus device? When to write a bus (newpcm uses
>a bus of it's own, if I'm not mistaken)?

If you refer to pcm attaching to sbc or gusc.  But those are pseudo
busses if I understood everything correctly, the same goes for miibus
and related busses (ppbus, smbus, iicbus).

>These problems are mostly distinct from each other, and their usefulness
>varies. Certainly, a tutorial covering newbus and the main bus types
>(usb, isa, pci) would be useful and not too difficult to write. CardBus
>and PCMCIA would be very useful, but we'll have to finish that first
>:-). 

Ehm, a tutorial covering the bus types.  You have no idea how much you
can write about ISA and PCI alone.

>But it gets complicated from there on. Writing a tutorial on even a
>subsection of CAM would be very time-consuming.

Write a reference so that we can finally convert the last drivers to
CAM/newbus. =)

>Julian had a device skeleton generator way back, I don't know if there
>is a newbus equivalent or not.

I think Peter [Wemm] wrote a skeleton one.

>Documenting the available debugging tools and useful debugging
>techniques would be mostly welcome. Aside from "how do I use the kernel
>debugger", use of tools such as truss, and loading symbol tables to
>kld's (see Greg Lehey's documentation on debugging vinum) would be
>useful tutorials.

Yeah yeah, coming up.  Stop whining. ;)
Hey, wait a sec, you said yesterday that you were bored.  Nice task for
you DCS ;)

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
Ain't gonna spend the rest of my Life, quietly fading away...


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

Re: Learning the FreeBSD Kernel

[Jeroen Ruigrok/Asmodai]

-On [2124 08:01], Mike Smith ([EMAIL PROTECTED]) wrote:
>> I can't agree with Mike Smith that reading the code is adequate.  It
>> certainly doesn't apply to newcomers, but it doesn't even apply to
>> seasoned hackers like Mike: the BSD style doesn't provide for adequate
>> comments, and so what you see from the code is mainly tactics, not
>> strategy.
>
>You miss my point; you don't want to be writing a driver until you know 
>what you're doing.  Documentation on an OS' driver interface won't teach 
>you that; it's something that's really only ever gleaned from experience.

This I agree on with Mike.  Writing device drivers isn't like writing an
application.

The documentation I am writing will definately not be a tutorial style
piece of documentation, but a reference guide with sufficient background
material so that people a bit familiar with FreeBSD on source level
(note the ``a bit'') will get enough ideas and clues from it to proceed
forwards.

I do not think making it a tutorial will be beneficial in the long run,
since I would have to discuss kernel sources, gdb, ddb and a number of
other things on the side.  But then again we will see where we will end.

I just know, from experience, that writing a driver involves more than
just code.

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
Ain't gonna spend the rest of my Life, quietly fading away...


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

Re: Query??

[Jeroen Ruigrok/Asmodai]

-On [2121 04:02], Saurabh Bhandari ([EMAIL PROTECTED]) wrote:
>Dear Sir,

Hi,

>I am a M.S. student with major as Computer Science. I am doing an 
>independent study with my professor. I have been told that BSD drivers are 
>not documented at this point of time. So I would like to document the BSD 
>Drivers.

You don't happen to be the student of the professor of rpi.edu (if I am
not mistaken) whom I just mailed back are you? =)

If you want to document the writing of the drivers, you might want to
stick around me, since I have been dogging in this subject for the past
few months.

>It would be a big help for me if you could answer the following questions:
>
>1)Are BSD drivers not really documented?(I fear that I may not end up 
>re-inventing the wheel)

Depends on which version of FreeBSD.  Prior to CURRENT (4.0) we used the
standard BSD/Unix way of writing device drivers.  That means we used
bdevsw[] and cdevsw[].  We recently collapsed both the character devices
and block devices into one cdevsw.

>2)I am new in this field. Will it be possible for you to tell me from where 
>should I start as I dont have any experience in this field?

Please see the email from Greg Lehey and myself in response to another
inquiry about writing device drivers, since it is too long to repeat
here.

Kind regards,

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
Ain't gonna spend the rest of my Life, quietly fading away...


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

Re: disappearing mount points after install

[Jeroen Ruigrok/Asmodai]

-On [2122 20:00], Marwan Fayed ([EMAIL PROTECTED]) wrote:
>There have been two suggestions both very related, both of which I have
>already considered. I thought perhaps my BIOS required a DOS partition so
>I installed RedHat 6.1 to be sure. Guess what? It worked!

My past recollection of slices/partitions wrt differences in them
between FreeBSD and Linux tend me to believe you cannot compare the two
since the system which handles them is highly different.

IIRC Linux allows you to install into extended partitions.  I cannot
remember that we supported (or that it is even possible) with FreeBSD.

Of course, this may all have changed and I have not been paying
attention. =)

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
Ain't gonna spend the rest of my Life, quietly fading away...


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

Re: Learning the FreeBSD Kernel

[Jeroen Ruigrok/Asmodai]

-On [2123 11:11], Greg Lehey ([EMAIL PROTECTED]) wrote:
>[adding -doc, which is more appropriate for some of the questions]
>
>On Saturday, 22 January 2000 at 23:06:41 -0500, Bill Maniatty wrote:

>> I have a student this semester in my Operating Systems class who would like
>> to become a bit more knowledgeable about systems software.  I suggested
>> that he learn a bit about how device drivers are written in FreeBSD
>> as a minor project.  My questions are:
>>
>> 1) Does any current documentation of how to write and/or install a
>>device driver exist in English (note C != English)?
>
>Yes, with reservations.

Big reservations.  The main question is, are you going to use the
default (old) style of Unix drivers (based on character and block
devices with their appropriate cdevsw and bdevsw), or are you willing to
have the student participate in the new style busspace/newbus system
which is present in CURRENT (soon to be released 4.0)?

>>We would love to have a level documentation like the document by
>>Pragmatic at http://thc.pimmel.com/files/thc/bsdkern.html, we are
>>looking for a how to guide.
>
>Somewhere we have a tutorial.  I think it's been retired because it's
>out of date, but it could be a very rewarding starting point for
>somebody who wanted to work his way into the material and either
>update it or bring out a new document based on the structure.  This
>would also give the student good visibility in the (Free)BSD
>community.

The Device Driver Writers Guide (DDWG) was retired because the contents
were too old to apply to modern day FreeBSD.  I am getting more and more
progress to get the relevant background information to:

a) write the busspace and newbus manpages
b) write a new DDWG which will include migration paths for old
   drivers to the new style

>> 2) If no existing documentation exists, would it be a good idea to
>>put together a sort of how to guide for a simple driver (with an
>>eye to generalization later if warranted)?

Heh, I am working on that, except things keep interrupting my work.

I was thinking of making a small document for the time being which gives
some general clue to the community for the new type drivers, or at least
summarises what has changed.  In /usr/src/sys/pci there is meteor.c
which still uses some old style driver code.  You can compare that to
most of the if_XYZ.c files by Bill Paul which make extensive use of the
new system.  Or take a look at Matthew N. Dodd's files and see even more
examples.

>> 3) If the answer to 2 is yes, can we get constructive help from the FreeBSD
>>community?
>
>Definitely.  -hackers would be the right forum there.  I would also
>personally commit to helping within the constraints of my other work.

I'll second Greg here.  I am here to write the documentation for this
subject (on voluntarily basis of course) and I think that questions
coming from your student, or from others for that matter, will make sure
I keep on top of things and document them.  Aside from -hackers, you
might want to consider -newbus, which is the forum to discuss newbus in
depth.

>> Assuming that this constitutes an interesting project, what would be
>> a good initial approach?  I was considering:
>> 1) Get and build the FreeBSD kernel (4.0?)

Please use this yes.  4.0 has IMHO better bus architecture code to look
into for writing drivers.

>> 2) Choose a non-essential device with a simple preexisting driver.
>> 3) Remove all trace of the driver from the kernel source.
>> 4) Reapply the changes used to install the driver (perhaps one step at a time).
>>We could suggest some simple sanity checks to support stepwise refinement.
>
>(1) and (2) are a good start.  You don't need to remove the old
>driver; it would in fact make it easier for debugging purposes if it
>remained.  Instead, choose another major number and name, and write a
>new driver.  This procedure is definitely *not* documented, but it's
>the way we introduce new drivers, and I think a couple of other people
>who have done it would be pleased to help.

*nod*  There are certainly people who are be able and willing to help.

>A possibly better alternative is to find a device which isn't
>currently supported by FreeBSD and write a driver for it.  This would
>have the advantage that the work would also be a contribution to
>FreeBSD.  The question that I can't answer here is: what would be an
>appropriate device?

Definately not an ethernet card. *g*
Seems no-one can keep up with Bill Paul in that aspect. =)

You could try usb devices and contact Nick Hibma for his expertise on
that area.

Also make sure the vendor is not problematic with handing out
documentation.  Intel and Motorola are good examples of companies who
have pdf's available for download.

>> If this is a good idea, I would like the following help from the FreeBSD
>> community:
>> 1) Identify a simple driver (perhaps something like a joystick
>>driver?)
>
>I don't know if

Re: How to write a device-driver?

[Jeroen Ruigrok/Asmodai]

-On [2109 04:01], Joachim Jdckel ([EMAIL PROTECTED]) wrote:
>Hello.

Hi,

>This is the first time that I try to do a hardware related programming,
>(if I ever will start and finish it...)
>I'm currently have no knowledge of that kind of programming, but I'd
>like to learn!

Welcome to the club. =P

>If I'd like to write a device driver for a given card, could you tell
>me, where I could read something about it (how to implement the
>interface to the kernel, where to place and name the files and so on). I
>read something about a device-driver tutorial under
>www.freebsd.org/tutorials/ddwg, but it seems, that this page isn't there
>anymore.

The placement is a bit dependant upon the version of FreeBSD.  Also, 4.0
uses a different architecture for drivers, commonly called newbus.

Also, the old Device Driver guide has been removed due its obsoletion
factor for 3.x and 4.0.  I am currently writing the 4.x newbus
documentation and trying to get a new DDWG up.  Not an easy task,
especially when one has to learn a lot himself still.

You could best look at /usr/src/sys, since that's where all kernel
related code goes.

>And maybe you could give me a tip, whats the best point to start, a
>linux-device-driver, something like a specification of the different
>chips on the card (it seems, that there is no documentation of the card
>from the manufacturer), or could I listen on the data, which is posted
>between the system and the driver under windows? whatever...

Linux drivers are fun as reference (not), mainly due to their weird use
of jiffies(), inb() and outb() and the like.

Most of the time the driver writers nag as long as possible at the
vendor's door until we get documentation.  Some of us are particulary
hesitant about accepting NDA's.

The best thing to do is take the card and write/type all the part
numbers on the chips on a piece of paper/temporary file.  And then you
can go search for the datasheets of those parts at their respective
vendor.  Some datasheets are not needed, others are very much the
essence.

Sometimes Windows drivers' .inf files come in handy for some id's abut
the vendor and the card.

How about letting loose a little bit more info on this card? =)

-- 
Jeroen Ruigrok van der Werven/Asmodai   asmodai@[wxs.nl|bart.nl]
Documentation nutter.  *BSD: Technical excellence at its best...  
The BSD Programmer's Documentation Project 
We must all hang together, else we shall all hang separately...


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

Re: Dell PowerEdge 2400 & RCC PCI chipset?

[Jeroen Ruigrok/Asmodai]

[ Please strip either smp or hackers on the next replies ]

-On [2112 00:00], Kenneth D. Merry ([EMAIL PROTECTED]) wrote:
>
>Anyone have a URL for RCC?

I just spend 30 minutes digging.

No URL to be find.  All tech forums have URL's for all participants,
except for RCC (Reliance Computer Corporation).

-- 
Jeroen Ruigrok van der Werven/Asmodai   asmodai@[wxs.nl|bart.nl]
Documentation nutter.  *BSD: Technical excellence at its best...  
The BSD Programmer's Documentation Project 
We must all hang together, else we shall all hang separately...


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

Re: wchar support?

[Jeroen Ruigrok/Asmodai]

-On [19991223 12:00], Nik Clayton ([EMAIL PROTECTED]) wrote:
>On Tue, Dec 21, 1999 at 08:30:21PM +0100, Jeroen Ruigrok/Asmodai wrote:
>> -On [19991221 18:25], Nik Clayton ([EMAIL PROTECTED]) wrote:
>> >I'm trying to compile OpenJade 1.3, a C++ application, for the Doc. Proj.
>> >The build fails with
>> 
>> Bah, you beat me to it ;)
>
>If this is going to be a 'fixed in -current' problem, please take the 
>lead.  I've only got the resources to run a -stable machine at the moment.

Nah, we need to do this both on CURRENT and STABLE, but you can count on
me to test the things on CURRENT.

I was merely commenting on the idea that I think you are somehow psychic
to know my to-do list. ;)

OTOH, David O`Brien was kind enough to let me know that there was a
wchar project this year and advised to browse the list archives.

-- 
Jeroen Ruigrok van der Werven/Asmodai   asmodai@[wxs.nl|bart.nl]
Documentation nutter.  *BSD: Technical excellence at its best...  
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
So take a look at me now, well there's just an empty space...


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

Re: wchar support?

[Jeroen Ruigrok/Asmodai]

-On [19991221 18:25], Nik Clayton ([EMAIL PROTECTED]) wrote:
>I'm trying to compile OpenJade 1.3, a C++ application, for the Doc. Proj.
>The build fails with

Bah, you beat me to it ;)

>LangObj.cxx:15: wchar.h: No such file or directory
>LangObj.cxx:16: wctype.h: No such file or directory
>gmake[2]: *** [LangObj.lo] Error 1

On CURRENT I have the above, but prefixed with a c, so:

cwchar.h and cwctype.h under /usr/include/g++/

I do see wchar and wctype.h as part of SUSv2 though.

I also see them as part of Linux libc.

But that's all I can tell about it.

HTH a bit Nik,

-- 
Jeroen Ruigrok van der Werven/Asmodai   asmodai@[wxs.nl|bart.nl]
Documentation nutter.  *BSD: Technical excellence at its best...  
The BSD Programmer's Documentation Project 
A rose is a rose is a rose is a rose...


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

machine/bus.h

[Jeroen Ruigrok/Asmodai]

Hi,

machine/bus.h claims, in its comment section, that it supports 8 byte
read/writes, but never in the whole file does it declare anything
remotely akin to bus_space_read_8().

Any reason why not?

The outcome of this answer will determine whether I make a patch to
correct the comments or add the missing declararions.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Pleasure's a sin, and sometimes sin's a pleasure.


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

Re: soundcard.h

[Jeroen Ruigrok/Asmodai]

On [19991021 12:00], Sheldon Hearn ([EMAIL PROTECTED]) wrote:
>On Wed, 20 Oct 1999 22:19:29 +0200, Jeroen Ruigrok/Asmodai wrote:
>
>> I have a soundcard.h in both include/sys and include/machine.
>> 
>> Which should have preference over the other, why does one simply not
>> include the other.  In other words, why two _exactly_ the same files?
>
>revision 1.97
>date: 1999/09/05 07:58:28;  author: peter;  state: Exp;  lines: +6 -6
>Only install backwards compat symlink for  if using
>the default SHARED=copies, otherwise the kernel source tree gets modified
>if /usr/include/machine is a symlink to the source tree (which is not the
>case by default).  Nothing in our src tree uses .

Pointy hat please.

I only looked my means of more, not an actual ls -asl of those
directories.  Now I noticed the symlink.

*sigh*

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Network/Security SpecialistBSD: Technical excellence at its best
He travels the fastest who travels alone.


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

soundcard.h

[Jeroen Ruigrok/Asmodai]

Hi,

just been messing with some more include files and I am curious about
something.

[Note: CURRENT system]

I have a soundcard.h in both include/sys and include/machine.

Which should have preference over the other, why does one simply not
include the other.  In other words, why two _exactly_ the same files?

Thanks,

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Distance lends enhancement to the view.


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

getopt.h

[Jeroen Ruigrok/Asmodai]

Well I searched the mailinglists and didn't really got further than
discovering that unistd.h goes a little way to provide functionality
which getopt.h from glibc provides.  And seeing that a question of Bill
early 1999 never got answered correctly.  I cc:'d Bruce on this since I
value his stylistic mindset on this issue.

I am starting on this topic since I need to port the source of an
application and I found the support of some part of getopt.h and lack of
support for the other part a kind of an oddity in the source tree.
That, plus a lot of our ports depend on it.  And it would be a waste for
using ports/devel/libgnugetopt when the solution is pretty small.

In unistd.h we have definitions for getopt, optarg, optind, opterr, and
optopt.

However this means we still have this to worry about:
[hacked up version of linux/glibc/posix/getopt.h]

#if !defined __GNU_LIBRARY__
#include 
#endif

struct option
{
#if defined __STDC__ && __STDC__
  const char *name;
#else
  char *name;
#endif
  int has_arg;
  int *flag;
  int val;
};

#define no_argument 0
#define required_argument   1
#define optional_argument   2

#if defined __STDC__ && __STDC__
extern int getopt_long (int __argc, char *const *__argv, const char *__shortopts,
const struct option *__longopts, int *__longind);
extern int getopt_long_only (int __argc, char *const *__argv,
 const char *__shortopts,
 const struct option *__longopts, int *__longind);

extern int _getopt_internal (int __argc, char *const *__argv,
 const char *__shortopts,
 const struct option *__longopts, int *__longind,
 int __long_only);
#endif /* __STDC__ */

I think the above inclusion of ctype.h can be forgotten about when we
include sys/types.h and sys/cdefs.h such as unistd.h does.  So that
effectively leaves us with one struct, three defines and three
functions.

The things I propose to add to unistd.h are the following:

struct option
{
char*name;
int has_arg;
int *flag;
int val;
};

#define no_argument 0
#define required_argument   1
#define optional_argument   2

extern int getopt_long (int, char *const [], const char *,
const struct option *, int *);
extern int getopt_long_only (int, char *const [], const char *,
 const struct option *, int *);
extern int _getopt_internal (int, char *const [], const char *,
 const struct option *, int *, int );

This should enable us to compile programs which require getopt.h by
simply including unistd.h.

I would like to hear any constructive comments on this.  Mostly on the
three #define's.

regards,

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
For country, children, hearth, and home.


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

Re: On pthreads [Was: Re: I was accepted to LokiHack '99 at Atlanta Linux Showcase]

[Jeroen Ruigrok/Asmodai]

On [19991006 04:02], Brian F. Feldman ([EMAIL PROTECTED]) wrote:
>What do you all think about
>http://www.FreeBSD.org/~green/OpenBSD.libc_r.cancel.patch
>? I isolated the set of commits that added cancelling to OpenBSD's
>libc_r, and it seems (since they took it from us originally :) it
>should be relatively simple to port :/

I knew you were working on importing the OpenBSD pthread_cancel.

Any idea how much fun it will be to get this into FreeBSD?

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
All for one, one for all.


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

On pthreads [Was: Re: I was accepted to LokiHack '99 at Atlanta Linux Showcase]

[Jeroen Ruigrok/Asmodai]

On [19991004 13:04], Daniel Eischen ([EMAIL PROTECTED]) wrote:
>> Do you mean pthreads?
>>
>> If so, we still do not have a pthread_cancel in our libc_r which could
>> greatly make things harder to implement. I think OpenBSD has one and we
>> might do well to look at that one.
>
>We could implement pthread_cancel rather easily (I have some crufty
>patches lying around somewhere to do it), but it wouldn't be nearly
>POSIX compliant.  Some non-cancellable routines would be cancellable,
>and vice-versa I think too.   

We need to make a start somewhere, since no pthread_cancel makes us even
less compliant =P

>We need to take a different approach to our threads library in the
>form of scheduler activations.  I _can_ hack in the pthread_cancel
>routines into our current libc_r, but I'd much rather spend my
>time looking into scheduler activations which will better solve
>the problem.

I neither have the docs, experience nor time to be of any help save that
I can try patches/compilations for you.

I found these people in reference to libc_r whom could prove helpful or
insightful for your endeavours:

John Birrell <[EMAIL PROTECTED]>
Peter Dufault <[EMAIL PROTECTED]>

Good luck.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Seek, and ye shall find; knock, and it shall be opened unto you.


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

Re: Developer assessment (was Re: A bike shed ...)

[Jeroen Ruigrok/Asmodai]

[This is only informative for others willing to participate, after this
it should probably no longer hit -hackers since it's getting off topic]

On [19991004 14:02], Michael Kennett ([EMAIL PROTECTED]) wrote:
>Hi Jeoren,

Almost ;)

s/eor/ero

>> I am already going to do this kind of stuff for the Dutch (Free)BSD User
>> Group, so I imagine I could as well start work on this one as well.
>> 
>> I even have a list of interesting FAQs on my homepage which I really
>> need to expand.
>> 
>> Feel free to e-mail me interesting topics/faqs/information which is
>> deemed hackers/new-hackers worthy.
>
>I certainly will. But, please, don't think you're alone on this project.
>Next weekend I'll try to knock something up. I'll send it along to you
>when I'm done.

OK Cool.

If you look at http://home.wxs.nl/~asmodai/bsd.html
and
http://home.wxs.nl/~asmodai/programlinks.html

you know what you don't have to send since I already have it ;)

I will cast it into a DocBook form and will generate the HTML from
there.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Might makes right.


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

Re: Developer assessment (was Re: A bike shed ...)

[Jeroen Ruigrok/Asmodai]

On [19991004 13:42], Michael Kennett ([EMAIL PROTECTED]) wrote:

>This 'how-to-help-yourself' document wouldn't have to be long. But it
>could contain references to the FreeBSD handbook, the FAQ, and other
>stuff that people put together (eg. Gregs pages on vinum, Brian Somers
>pages on ppp, + many others), in addition to some general internet
>resources (eg. www.faqs.org), and general unix introductions.
>Ideally, this 'meta-FAQ' would only be a few pages in length. It's role
>would be as a quick signpost to material that people have found useful
>before.

Allow me to cast the first stone then.

I am already going to do this kind of stuff for the Dutch (Free)BSD User
Group, so I imagine I could as well start work on this one as well.

I even have a list of interesting FAQs on my homepage which I really
need to expand.

Joy! More work ;)

Feel free to e-mail me interesting topics/faqs/information which is
deemed hackers/new-hackers worthy.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
The descent to hell is easy.


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

Re: I was accepted to LokiHack '99 at Atlanta Linux Showcase

[Jeroen Ruigrok/Asmodai]

On [19991004 11:42], Stephen Hocking ([EMAIL PROTECTED]) wrote:
>I would like to point out that they use the SDL library for many of their 
>products. We have this in our ports section, but it does have a bug in that we 
>get a threads crash when doing sound & video simultaneously. The aliens demo 
>displays this fault rather well. Sometimes it works, other times it doesn't, 
>there's something timing related. I suspect something needs to be protected by 
>a mutex somewhere.

Do you mean pthreads?

If so, we still do not have a pthread_cancel in our libc_r which could
greatly make things harder to implement. I think OpenBSD has one and we
might do well to look at that one.

Now if we mean another threads implementation alltogether, than you can
just ignore the above =)

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Fame is the perfume of heroic deeds.


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

Re: Developer assessment (was Re: A bike shed ...)

[Jeroen Ruigrok/Asmodai]

[ snip good advice ] 

Now this is very good advice.

I am certainly going to keep Darryl's comments somewhere for easy
reference in order to make sure I at least never forget where I came
from and how to treat others.

I think everybody should heed this advice.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Fame is the perfume of heroic deeds.


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

Re: A bike shed (any colour will do) on greener grass...

[Jeroen Ruigrok/Asmodai]

On [19991002 20:18], Poul-Henning Kamp ([EMAIL PROTECTED]) wrote:

>My last pamphlet was sufficiently well received that I was not
>scared away from sending another one, and today I have the time
>and inclination to do so.

I am glad you took the time to write this out. I only wish more people
would communicate more verbally about the what and whatnot.

>The thing which have triggered me this time is the "sleep(1) should
>do fractional seconds" thread, which have pestered our lives for
>many days now, it's probably already a couple of weeks, I can't
>even be bothered to check.
>
>To those of you who have missed this particular thread: Congratulations.

I dare ask where this thread took place. Again I think it took place on
cvs-committers.

>It was a proposal to make sleep(1) DTRT if given a non-integer
>argument that set this particular grass-fire off.  I'm not going
>to say anymore about it than that, because it is a much smaller
>item than one would expect from the length of the thread, and it
>has already received far more attention than some of the *problems*
>we have around here.

Problems at hand [some of which were enspired to me by Marcel
Moolenaar]:

- cross compilation, this obviously does not work.

- lack of communication between the coders towards the -doc team. Need I
  dare say that pci_read_config, a lot of newbus stuff and god knows
  what else is still lacking from the documentation. I am working on it,
  but there's only so much I can grasp, understand and document each
  day.

- lack of communication of the indivudual developers amongst each other.
  I have seen patches floating around and I have seen NIL comments when
  asked for testing, comments and what not. One example were Marcel's
  sig_t changes.

>The sleep(1) saga is the most blatant example of a bike shed
>discussion we have had ever in FreeBSD.  The proposal was well
>thought out, we would gain compatibility with OpenBSD and NetBSD,
>and still be fully compatible with any code anyone ever wrote.
>
>Yet so many objections, proposals and changes were raised and
>launched that one would think the change would have plugged all
>the holes in swiss cheese or changed the taste of Coca Cola or
>something similar serious.

[snip bike shed analogy]

>In Denmark we call it "setting your fingerprint".  It is about
>personal pride and prestige, it is about being able to point
>somewhere and say "There!  *I* did that."  It is a strong trait in
>politicians, but present in most people given the chance.  Just
>think about footsteps in wet cement.

Ego, cherishing `babies' and the likes is something which doesn't work
in commercial environment, and probably even less so in open source
environments.

>I bow my head in respect to the original proposer because he stuck
>to his guns through this carpet blanking from the peanut gallery,
>and the change is in our tree today.  I would have turned my back
>and walked away after less than a handful of messages in that
>thread.

Problems which also arise is that people divert from the topics which
are at hand.

I don't know anything about the thread and I somewhat refuse to dig
through the committers archive by means of ftp in order to just read the
thread, because I still believe that these kind of things should have
been discussed on the appropriate lists.

>And that brings me, as I promised earlier, to why I am not subscribed
>to -hackers:
>
>I un-subscribed from -hackers several years ago, because I could
>not keep up with the email load.  Since then I have dropped off
>several other lists as well for the very same reason.

The load itself might not be the burden if only the signal-to-noise
ration would be a lot better. A lot of the topics at hand should've been
made to questions.

>And I still get a lot of email.  A lot of it gets routed to /dev/null
>by filters:  People like Brett Glass will never make it onto my
>screen, commits to documents in languages I don't understand
>likewise, commits to ports as such.  All these things and more go
>the winter way without me ever even knowing about it.
>
>This is where the greener grass comes into the picture:
>
>I wish we could reduce the amount of noise in our lists and I wish
>we could let people build a bike shed every so often, and I don't
>really care what colour they paint it.
>
>The first of these wishes is about being civil, sensitive and 
>intelligent in our use of email.
>
>If I could concisely and precisely define a set of criteria for
>when one should and when one should not reply to an email so that
>everybody would agree and abide by it, I would be a happy man, but
>I am too wise to even attempt that.
>
>But let me suggest a few pop-up windows I would like to see
>mail-programs implement whenever people send or reply to email
>to the lists they want me to subscribe to:

[fun, but somewhat non-practical pop-up windows removed]

>The second part of my wish is more emotional.  Obviously, the
>capacities we had manning the unfriendly fire in 

Re: umount(8) or unmount(2) ?

[Jeroen Ruigrok/Asmodai]

On [19991003 04:18], Martin Blapp ([EMAIL PROTECTED]) wrote:
>
>Since about 5 weeks I'm working on sanity checks and bug fixes
>for umount(8), mount(8) and mount_xxx(8). Poul Henning told
>me to mail to cvs-committers too, cause many clued people read it.

And don't bother to read -hackers.

>You'll find my patch and the readme for it on :
>
>http://www.attic.ch/patches/MOUNTPATCH-CURRENT-02101999-01
>http://www.attic.ch/patches/MOUNTPATCH-README
>
>I've implemented this as an idea from phk and it works very well. If we
>unmount a hanged nfs-mount - it hangs no in kernel (if busy), not in
>userland. This is a little step forward. Some side-effects of this
>part of my patch are, that some other PR's are fixed too :
>
>o [1999/02/03] bin/9893 NFS umount of regular file impossible
>s [1995/11/27] bin/841  stale nfs mounts cannot be umounted

People who think this is about NFS mounting only have obviously not read
the README on the sire Martin supplied. I urge a person who bothers to
comment on this, should read the README first and [politely] discuss any
points with Martin on this list.

For all I know about this subject I can at least say I like the proposed
sanity-checks. Sanity-checking is something we can always use.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Fame is the perfume of heroic deeds.


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

Re: I was accepted to LokiHack '99 at Atlanta Linux Showcase

[Jeroen Ruigrok/Asmodai]

On [19991002 04:18], Jason Nordwick ([EMAIL PROTECTED]) wrote:
>This wouldn't seem -hackers worthy, except I offfered to try to port
>it to freebsd-current.

I think the things you might need to have [the tools as they called it]
might be handy to know. And I think this is more hackers material.

>I thought that this would be interesting to people and that I might be able
>to get some advice from around here.  Following is the email thread that
>happened between Scott Draeker (president of Loki) and Sam Lantinga
>(Lead Programmer at Loki).  After that is the official offer letter
>with the library specifications (such as what sound library is used and
>graphics packages).  If anybody has any suggestions it would help me
>greatly.  I have already started looking at the sound library, since that it
>my weekest area.

Ok, 

what you want to bring along is a CURRENT box. With gmake, autoconf,
automake, libtool installed just to be sure that you have them ;)

Also, for the sound aspects under FreeBSD you should probably speak to
Cameron Grant who did most of the newpcm work under FreeBSD-CURRENT.

You of course want to be sure you have a complete /usr/src available on
the machine and probably another copy to work on or a repository from
which you can check out the appropriate stuff.

Your best/handiest editor should also be installed of course together
with any tools you use for development. Colourised diff, various things
from /usr/ports/devel, etc.

Hope this gives at least a start for you. And I hope others will give
you a hand towards some of the innards of the kernel with which they
have experience.

Hope this helps,

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Fame is the perfume of heroic deeds.


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

Re: FreeBSD driver for DPT SmartRAID V

[Jeroen Ruigrok/Asmodai]

On [19990930 08:14], Anthony Rubin ([EMAIL PROTECTED]) wrote:
>With the release of the Linux driver for the DPT SmartRAID V cards I imagine
>it is just a matter of time before we have a FreeBSD driver.  I sent the
>following message to DPT.
>
>>I know this may be a long shot, but here goes.  What would be the
>>possibilites of a FreeBSD driver for your SmartRAID V series?  I know one
>>will probably be created eventually now that you released your Linux driver
>>with source, but I was hoping for one in the next month or so that I could
>>purchase a SmartRAID V for use in a FreeBSD box that I have.  Thanks in
>>advance.

If not, bug for tech-docs to be released free of NDA, whereas the
FreeBSD hacker community will code the driver. This will impose no
support for the driver upon DPT. Make sure to emphasize that.

Another long shot. But it worked for other companies =)

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Fame is the perfume of heroic deeds.


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

Call for projects

[Jeroen Ruigrok/Asmodai]

Since no-one except Poul-Henning gave a start with this I thought I
might try my hand at this.

Given FreeBSD's rapid development over the last year a lot of things
around the releases have changed. Nik Clayton and his team are doing a
terrific job to keep up with the documentation.

However, what has been lacking, at least in my opinion, is the lack of
alerting less advanced, more time-restrained, however you wish to call
it, hackers of tasks which need to be fixed in FreeBSD. The PR system is
nice and works pretty well [thanks to a lot of people] but it is not
what I meant with my above words.

What I did mean though, is that when someone messes with source code at
large in FreeBSD to let the hacker/developer-community know of these
changes plus point out some areas which need to be fixed/looked-out with
these patches in place. Small-term projects.

Also, put out more patches on either -hackers or -current [depending on
what platform the patches aim at] and call for more test reviews to
eliminate more and more initial bugs upon introducing.

Plus, let the doc guys know what changes have been made and in which
places the docs should be altered. Doesn't take much, but remember that
not every docperson is a kernel hacker and vice versa, so UTSL, how well
intended doesn't always help in these cases.

All of this is merely a call for clearer communication between the
diverse efforts within the project as a whole and external hackers with
no access to the repository but who wish to send-pr diffs/patches to fix
up forgotten/neglected/overseen areas in the code.

Thanking you all in advance for helping on this.
It's together we make this project work...

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Any fool can make a rule  And every fool will mind it.


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

Re: submiting source code ?

[Jeroen Ruigrok/Asmodai]

* Dag-Erling Smorgrav (d...@flood.ping.uio.no) [990914 16:44]:
>Jeroen Ruigrok/Asmodai  writes:
>> The Unix Programming Environment by Rob Pike and Ritchie Kerninghan
>
>Ritchie Kernighan? Who's Ritchie Kernighan?

Thanks for you concern about my apparant inability to remember big
names correctly Erling-Dag =P

*grin*

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Network/Security SpecialistBSD: Technical excellence at its best
If Winter comes, can Spring be far behind?


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

Re: submiting source code ?

[Jeroen Ruigrok/Asmodai]

* Gustavo V G C Rios ([EMAIL PROTECTED]) [990910 04:14]:
>I use freebsd about +- 12 months ago. I have never did any thing serious
>at kernel level, nor i know anything about kernel desgin.

Start with:

Modern Operating Systems by Andrew S. Tanenbaum
The Design and Implementation of 4.4BSD by Marshall Kirk McKusick et al.
Unix Internals: The New Frontiers

Then you probably need more special in-depth books such as:

TCP/IP Illustrated by (R.I.P.) W. Richard Stevens
Unix Network Programming by W. Richard Stevens
The Unix Programming Environment by Rob Pike and Ritchie Kerninghan
Advanced Programming in the Unix Environment by W. Richard Stevens

>Suppose, i would like to spend time and patience learnig Fbsd internals.
>If, later, i were able to code something to freebsd, and suppose i do,
>what (or better, how) should i do to have my source accepted by the core
>team?

send-pr after you have tested, style(9)'d, documented your code and
tested you patches against a clean checked out source base.

>What about coding style ?

As Chris said, style(9)

>What are the golden rules to have my sources widely accepted by freebsd
>community?

Don't go the Linux way which tends to favor bloat over solid code.
Portability and correctness of code is more important than features.

>PS: This is my first attempt to start touching the kernel, so, don't
>blame, if i wrote something wrong.

That's ok, it's a long way before you actually will start touching the
sources though, it involves a lot of RTFM'ing and UTSL'ing first.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Workers of the world, unite!


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

Re: A Challenge

[Jeroen Ruigrok/Asmodai]

* Nate Williams ([EMAIL PROTECTED]) [990910 07:14]:
>In any case, if you install a recent version of FreeBSD, I doubt Mr. NT
>is capable of crashing FreeBSD from externally.  Just make sure he
>doesn't have an account on it, since it's much easier to cause Denial Of
>Service attacks if you don't spend alot of time setting up limits and
>such.

Going even further than what Nate said, remove all accounts you don't
need. Give only accounts to those who need to admin the box, other than
that DO NOT give away accounts.

Make sure the security log files sent by email are being sent to the
correct persons.

Remove /usr/src and compile kernels on a secondary host so you are sure
that compiling stuff on the firewall is hard after a compromise.

Use ssh and ditch telnet.

read security(9)

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
If Winter comes, can Spring be far behind?


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

Re: A Challenge

[Jeroen Ruigrok/Asmodai]

* Nate Williams (n...@mt.sri.com) [990910 07:14]:
>In any case, if you install a recent version of FreeBSD, I doubt Mr. NT
>is capable of crashing FreeBSD from externally.  Just make sure he
>doesn't have an account on it, since it's much easier to cause Denial Of
>Service attacks if you don't spend alot of time setting up limits and
>such.

Going even further than what Nate said, remove all accounts you don't
need. Give only accounts to those who need to admin the box, other than
that DO NOT give away accounts.

Make sure the security log files sent by email are being sent to the
correct persons.

Remove /usr/src and compile kernels on a secondary host so you are sure
that compiling stuff on the firewall is hard after a compromise.

Use ssh and ditch telnet.

read security(9)

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
If Winter comes, can Spring be far behind?


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

Re: submiting source code ?

[Jeroen Ruigrok/Asmodai]

* Gustavo V G C Rios (gr...@ddsecurity.com.br) [990910 04:14]:
>I use freebsd about +- 12 months ago. I have never did any thing serious
>at kernel level, nor i know anything about kernel desgin.

Start with:

Modern Operating Systems by Andrew S. Tanenbaum
The Design and Implementation of 4.4BSD by Marshall Kirk McKusick et al.
Unix Internals: The New Frontiers

Then you probably need more special in-depth books such as:

TCP/IP Illustrated by (R.I.P.) W. Richard Stevens
Unix Network Programming by W. Richard Stevens
The Unix Programming Environment by Rob Pike and Ritchie Kerninghan
Advanced Programming in the Unix Environment by W. Richard Stevens

>Suppose, i would like to spend time and patience learnig Fbsd internals.
>If, later, i were able to code something to freebsd, and suppose i do,
>what (or better, how) should i do to have my source accepted by the core
>team?

send-pr after you have tested, style(9)'d, documented your code and
tested you patches against a clean checked out source base.

>What about coding style ?

As Chris said, style(9)

>What are the golden rules to have my sources widely accepted by freebsd
>community?

Don't go the Linux way which tends to favor bloat over solid code.
Portability and correctness of code is more important than features.

>PS: This is my first attempt to start touching the kernel, so, don't
>blame, if i wrote something wrong.

That's ok, it's a long way before you actually will start touching the
sources though, it involves a lot of RTFM'ing and UTSL'ing first.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Workers of the world, unite!


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

Re: Ariel RS 2000 T1/EI card

[Jeroen Ruigrok/Asmodai]

[snip]

Please people. When posting messages DON'T reply to other messages
if the topic has NOTHING to do with the topic being discussed.

This obviously messes up reply-to headers, makes the archives less
useful as well and generally screws up threading in MUA's.

Thanks.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
...fools rush in where Daemons fear to tread.


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

Re: Ariel RS 2000 T1/EI card

[Jeroen Ruigrok/Asmodai]

[snip]

Please people. When posting messages DON'T reply to other messages
if the topic has NOTHING to do with the topic being discussed.

This obviously messes up reply-to headers, makes the archives less
useful as well and generally screws up threading in MUA's.

Thanks.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
...fools rush in where Daemons fear to tread.


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

Re: How to go about making a compiler port

[Jeroen Ruigrok/Asmodai]

* Simon Marlow ([EMAIL PROTECTED]) [990912 13:05]:

>I'd like to make a port for our Haskell compiler, GHC (see
>http://research.microsoft.com/users/t-simonm/ghc).  There are some subtle
>problems with this:
>
>   - GHC depends on itself.  That is, you need GHC
> installed in order to build GHC.
>   - GHC depends on Happy, our parser generator.
>   - Happy depends on GHC (it's written in Haskell).

>So, one solution would be to provide a binary port, say ghc-bin, which would
>install a binary distribution.  I checked the modula-3 port, and it doesn't
>seem to have a binary port, so what's the accepted way of doing this?

Well, you could also take a peek at net/cvsup-bin
Another binary used a lot. It might give some ideas.

>It's possible to bootstrap GHC from intermediate C files, but it's a bit
>fiddly and I'd prefer not to do this if possible.  However, one thing that
>occurs to me is that the port could bootstrap itself from C if you say 'make
>BOOTSTRAP=YES', and otherwise attempt to build using an installed GHC.

*nod*
That could be a solution. Although it requires a clue.
Normally one does:
make
make install
make clean

What could be a solution would be to make and after the make go
interactive and ask to try to bootstrap from C or use the GHC-binary.
print/apsfilter is a good example of interactive stuff...

>Any thoughts greatly appreciated.

These are just some random thoughts. Surely I am missing some pitfalls,
but these might spark some ideas.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
If I am telling you the Truth now, do you believe it?


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

Re: How to go about making a compiler port

[Jeroen Ruigrok/Asmodai]

* Simon Marlow (simon...@microsoft.com) [990912 13:05]:

>I'd like to make a port for our Haskell compiler, GHC (see
>http://research.microsoft.com/users/t-simonm/ghc).  There are some subtle
>problems with this:
>
>   - GHC depends on itself.  That is, you need GHC
> installed in order to build GHC.
>   - GHC depends on Happy, our parser generator.
>   - Happy depends on GHC (it's written in Haskell).

>So, one solution would be to provide a binary port, say ghc-bin, which would
>install a binary distribution.  I checked the modula-3 port, and it doesn't
>seem to have a binary port, so what's the accepted way of doing this?

Well, you could also take a peek at net/cvsup-bin
Another binary used a lot. It might give some ideas.

>It's possible to bootstrap GHC from intermediate C files, but it's a bit
>fiddly and I'd prefer not to do this if possible.  However, one thing that
>occurs to me is that the port could bootstrap itself from C if you say 'make
>BOOTSTRAP=YES', and otherwise attempt to build using an installed GHC.

*nod*
That could be a solution. Although it requires a clue.
Normally one does:
make
make install
make clean

What could be a solution would be to make and after the make go
interactive and ask to try to bootstrap from C or use the GHC-binary.
print/apsfilter is a good example of interactive stuff...

>Any thoughts greatly appreciated.

These are just some random thoughts. Surely I am missing some pitfalls,
but these might spark some ideas.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
If I am telling you the Truth now, do you believe it?


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

Re: CS Project

[Jeroen Ruigrok/Asmodai]

* Daniel O'Connor (docon...@gsoft.com.au) [990909 07:15]:
>On 09-Sep-99 Gustavo V G C Rios wrote:
>> > I would not be able to see any other proccess which i am not the
>> > owner, top would indicated, only 8 proccess, for this current scenario.
>> > 
>> > Linux already have such a facility!
>
>Hack ps and turn off procfs :)

I think a sysctl would in order to switch this behaviour on or off.
Some people prefer total obscurity, others don't give a dime about
whether or not mary sees that jim is running a make.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Unto the pure all things are pure.


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

Re: CS Project

[Jeroen Ruigrok/Asmodai]

* Daniel O'Connor ([EMAIL PROTECTED]) [990909 07:15]:
>On 09-Sep-99 Gustavo V G C Rios wrote:
>> > I would not be able to see any other proccess which i am not the
>> > owner, top would indicated, only 8 proccess, for this current scenario.
>> > 
>> > Linux already have such a facility!
>
>Hack ps and turn off procfs :)

I think a sysctl would in order to switch this behaviour on or off.
Some people prefer total obscurity, others don't give a dime about
whether or not mary sees that jim is running a make.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Unto the pure all things are pure.


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

Re: CFD: "bogomips" CPU performance metric

[Jeroen Ruigrok/Asmodai]

* Satoshi - Ports Wraith - Asami (as...@freebsd.org) [990903 12:14]:
> * From: Jonathan Lemon 
>
> * hw.clockrate:   132 
>
> * Doing this for Pentium and better systems should be trivial.  Doing
> * it for 486 and lower would just add a timing loop.  Doing it for SMP
> * would be harder.
> * 
> * hw.cpu0.clockrate:  233
> * hw.cpu1.clockrate:  233
> * 
> * Possibly?  The implementer gets to pick a better name than these.
>
>hw.clockrate.cpu0: 233
>hw.clockrate.cpu1: 233
>
>(cpu0 only for uni-procs, of course).

This sounds like a good solution.

I don't know why we can't detect speed on SMP boxes and I doubt the
code will make things clear to me [seeing my third rank coding
abilities].

But we could probe the first CPU, get it's clockspeed and since it's
SMP be certain that all other CPU's would have the same speed.
This might not be the cleanest solution should AMP type systems ever
surface. [If they ever]

Else, anyone care to detail exactly why we can't detect it?

cheers,

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Knowledge comes, but wisdom lingers.


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

Re: CFD: "bogomips" CPU performance metric

[Jeroen Ruigrok/Asmodai]

* Satoshi - Ports Wraith - Asami ([EMAIL PROTECTED]) [990903 12:14]:
> * From: Jonathan Lemon <[EMAIL PROTECTED]>
>
> * hw.clockrate:   132 
>
> * Doing this for Pentium and better systems should be trivial.  Doing
> * it for 486 and lower would just add a timing loop.  Doing it for SMP
> * would be harder.
> * 
> * hw.cpu0.clockrate:  233
> * hw.cpu1.clockrate:  233
> * 
> * Possibly?  The implementer gets to pick a better name than these.
>
>hw.clockrate.cpu0: 233
>hw.clockrate.cpu1: 233
>
>(cpu0 only for uni-procs, of course).

This sounds like a good solution.

I don't know why we can't detect speed on SMP boxes and I doubt the
code will make things clear to me [seeing my third rank coding
abilities].

But we could probe the first CPU, get it's clockspeed and since it's
SMP be certain that all other CPU's would have the same speed.
This might not be the cleanest solution should AMP type systems ever
surface. [If they ever]

Else, anyone care to detail exactly why we can't detect it?

cheers,

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Knowledge comes, but wisdom lingers.


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

Re: Propose mdoc fix regarding ERRORS section

[Jeroen Ruigrok/Asmodai]

* Mike Pritchard (m...@mpp.pro-ns.net) [990828 11:44]:
>>Category:   docs
>>Synopsis:   src/lib/libc/sys/*.2 misc patch pack
>- first column in most ERROR lists is too narrow. Normalize their width.
>
>Right now we have a problem with our on-line man pages.  Most were
>written when the length of errno's were only 6 - 8 characters long.
>Now we have errno's that can be up to 15 characters long.  Many
>of our man pages have the following mdoc instruction (or something
>similar) to ensure that the field width for the errno is appropriate:
>
>.Bl -tag -width EBADFXXX

Most lists do actually. But you already know =)

>.Bl -tag -width Er
>
>Which will reserve enough space for the errno name based on what
>width the Er macro specifies.  Right now it doesn't allocate enough
>width to contain our largest errno's.  
>
>I propose that we fix mdoc to allocate enough width when the second
>form is specified, and then change all of the man pages to use that
>format in the ERRORS section.

I think using -width Er and setting the Er constant to a higher value
might be the best thing. Offcourse we need to check all of the manpages
in order whether they use -width EBLAHBLAH or -width Er.

If you need help, please yell.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Fame is the perfume of heroic deeds.


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

Re: Propose mdoc fix regarding ERRORS section

[Jeroen Ruigrok/Asmodai]

* Mike Pritchard ([EMAIL PROTECTED]) [990828 11:44]:
>>Category:   docs
>>Synopsis:   src/lib/libc/sys/*.2 misc patch pack
>- first column in most ERROR lists is too narrow. Normalize their width.
>
>Right now we have a problem with our on-line man pages.  Most were
>written when the length of errno's were only 6 - 8 characters long.
>Now we have errno's that can be up to 15 characters long.  Many
>of our man pages have the following mdoc instruction (or something
>similar) to ensure that the field width for the errno is appropriate:
>
>.Bl -tag -width EBADFXXX

Most lists do actually. But you already know =)

>.Bl -tag -width Er
>
>Which will reserve enough space for the errno name based on what
>width the Er macro specifies.  Right now it doesn't allocate enough
>width to contain our largest errno's.  
>
>I propose that we fix mdoc to allocate enough width when the second
>form is specified, and then change all of the man pages to use that
>format in the ERRORS section.

I think using -width Er and setting the Er constant to a higher value
might be the best thing. Offcourse we need to check all of the manpages
in order whether they use -width EBLAHBLAH or -width Er.

If you need help, please yell.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Fame is the perfume of heroic deeds.


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

Re: What's new in Linux 2.4

[Jeroen Ruigrok/Asmodai]

* Peter Jeremy (jere...@gsmx07.alcatel.com.au) [990804 01:13]:
> Jordan recently mentioned "Wonderful World of Linux 2.4 (Second
> Edition)" .
> 
> This article makes the statement "Linux is still the only operating
> system completely compatible with the IPv4 specification", which is
> further expanded in a followup article by :
> .
> 
> Does anyone know what Joe and Soren are talking about here?  I was
> under the impression that BSD (probably 4.3BSD) was the Reference
> Implementation for IPv4.  Where does FreeBSD differ from the relevant
> RFCs?

I think that Linux is not fully compliant. Mayhaps it is nowadays, but
the last time I delved around there were some problems regarding ARP,
some ICMP [which was recently fixed IIRC] and a few others which I
cannot remember from the top of my head though...

I think some other people in here might elaborate some more.

The point with the RFC's are the MAY, SHOULD and MUST keywords. One can
be fully compatible and yet miss a lot of features. Oh wait, we're
talking Linux here. Hmm, then the features will be present.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: What's new in Linux 2.4

[Jeroen Ruigrok/Asmodai]

* Peter Jeremy ([EMAIL PROTECTED]) [990804 01:13]:
> Jordan recently mentioned "Wonderful World of Linux 2.4 (Second
> Edition)" .
> 
> This article makes the statement "Linux is still the only operating
> system completely compatible with the IPv4 specification", which is
> further expanded in a followup article by <[EMAIL PROTECTED]>:
> .
> 
> Does anyone know what Joe and Soren are talking about here?  I was
> under the impression that BSD (probably 4.3BSD) was the Reference
> Implementation for IPv4.  Where does FreeBSD differ from the relevant
> RFCs?

I think that Linux is not fully compliant. Mayhaps it is nowadays, but
the last time I delved around there were some problems regarding ARP,
some ICMP [which was recently fixed IIRC] and a few others which I
cannot remember from the top of my head though...

I think some other people in here might elaborate some more.

The point with the RFC's are the MAY, SHOULD and MUST keywords. One can
be fully compatible and yet miss a lot of features. Oh wait, we're
talking Linux here. Hmm, then the features will be present.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: no elf(5) man page (docs/7914)

[Jeroen Ruigrok/Asmodai]

* Wes Peters (w...@softweyr.com) [990803 10:13]:
> Jeroen Ruigrok/Asmodai wrote:
> > * Andy Doran (a...@netbsd.org) [990802 00:53]:
> > > Wes Peters writes:

> > > > NetBSD doesn't have one as of 1.4, so they may be interested in yours. 
> > > > ;^)
> > >
> > > It'd be cool if Asmodai could bounce this around one of the NetBSD lists
> > > once it's near completion. tech-toolchain@ or tech-userlevel@ would be the
> > > right place I guess.
> > 
> > I already saw some differences in the stucture member names though, so
> > ye will need to adjust those.
> 
> Ain't cooperation great?  ;^)
> 
> Now if our OpenBSD friend will provide us with a mailing list or doc reviewer
> there, we can kill THREE birds with one stone.

I know a committer there =)

I have cc:'d him and hope he likes the idea as well. [hey Art ;)]

OpenBSD, and pardon if saying it wrongly here, took the definitions from 
elf_common.h, so that's at least consistent.

NetBSD defines some macros with other values =\
There goes some compatibility.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: no elf(5) man page (docs/7914)

[Jeroen Ruigrok/Asmodai]

* Wes Peters ([EMAIL PROTECTED]) [990803 10:13]:
> Jeroen Ruigrok/Asmodai wrote:
> > * Andy Doran ([EMAIL PROTECTED]) [990802 00:53]:
> > > Wes Peters writes:

> > > > NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^)
> > >
> > > It'd be cool if Asmodai could bounce this around one of the NetBSD lists
> > > once it's near completion. tech-toolchain@ or tech-userlevel@ would be the
> > > right place I guess.
> > 
> > I already saw some differences in the stucture member names though, so
> > ye will need to adjust those.
> 
> Ain't cooperation great?  ;^)
> 
> Now if our OpenBSD friend will provide us with a mailing list or doc reviewer
> there, we can kill THREE birds with one stone.

I know a committer there =)

I have cc:'d him and hope he likes the idea as well. [hey Art ;)]

OpenBSD, and pardon if saying it wrongly here, took the definitions from 
elf_common.h, so that's at least consistent.

NetBSD defines some macros with other values =\
There goes some compatibility.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: no elf(5) man page (docs/7914)

[Jeroen Ruigrok/Asmodai]

* Andy Doran (a...@netbsd.org) [990802 00:53]:
> Wes Peters writes:
> 
> > NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^)
> 
> It'd be cool if Asmodai could bounce this around one of the NetBSD lists
> once it's near completion. tech-toolchain@ or tech-userlevel@ would be the
> right place I guess.

Will do.

I already saw some differences in the stucture member names though, so
ye will need to adjust those.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: no elf(5) man page (docs/7914)

[Jeroen Ruigrok/Asmodai]

* Andy Doran ([EMAIL PROTECTED]) [990802 00:53]:
> Wes Peters writes:
> 
> > NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^)
> 
> It'd be cool if Asmodai could bounce this around one of the NetBSD lists
> once it's near completion. tech-toolchain@ or tech-userlevel@ would be the
> right place I guess.

Will do.

I already saw some differences in the stucture member names though, so
ye will need to adjust those.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: No elf(5) man page (docs/7914)

[Jeroen Ruigrok/Asmodai]

* Wes Peters (w...@softweyr.com) [990801 07:12]:
> Jeroen Ruigrok/Asmodai wrote:
> > 
> > * Nik Clayton (n...@nothing-going-on.demon.co.uk) [990730 23:37]:
> > >
> > > We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
> > >
> > > Does anyone feel up to writing one?
> > 
> > Saw it before, noticed it, placed on my to-do list. If no-one objects
> > I'll submit a manpage per a.out(5) style tomorrow for review untill it's
> > ready for inclusion.
> 
> NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^)

Same goes for OpenBSD and a lot of Linux distro's as far as I have been
able to discern.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: No elf(5) man page (docs/7914)

[Jeroen Ruigrok/Asmodai]

* Wes Peters ([EMAIL PROTECTED]) [990801 07:12]:
> Jeroen Ruigrok/Asmodai wrote:
> > 
> > * Nik Clayton ([EMAIL PROTECTED]) [990730 23:37]:
> > >
> > > We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
> > >
> > > Does anyone feel up to writing one?
> > 
> > Saw it before, noticed it, placed on my to-do list. If no-one objects
> > I'll submit a manpage per a.out(5) style tomorrow for review untill it's
> > ready for inclusion.
> 
> NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^)

Same goes for OpenBSD and a lot of Linux distro's as far as I have been
able to discern.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: No elf(5) man page (docs/7914)

[Jeroen Ruigrok/Asmodai]

* Sheldon Hearn (sheld...@uunet.co.za) [990801 00:35]:
> 
> 
> On Fri, 30 Jul 1999 23:46:26 +0200, Jeroen Ruigrok/Asmodai wrote:
> 
> > If no-one objects I'll submit a manpage per a.out(5) style tomorrow
> > for review untill it's ready for inclusion.
> 
> Anyone who objects to your submissions is a woes -- real bastards wait
> for you to do the work before shooting you down. :-)

Now, that gives me a good feeling =P

I already started work on it...

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: Is the _Device Driver Writers Guide_ still apropos?

[Jeroen Ruigrok/Asmodai]

* Nik Clayton (n...@freebsd.org) [990801 00:35]:
> How does the attached patch grab you?

I think it perfect...

Now to find the time to wrote the sucker ;)

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: Is the _Device Driver Writers Guide_ still apropos?

[Jeroen Ruigrok/Asmodai]

* Nik Clayton ([EMAIL PROTECTED]) [990801 00:35]:
> How does the attached patch grab you?

I think it perfect...

Now to find the time to wrote the sucker ;)

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: No elf(5) man page (docs/7914)

[Jeroen Ruigrok/Asmodai]

* Sheldon Hearn ([EMAIL PROTECTED]) [990801 00:35]:
> 
> 
> On Fri, 30 Jul 1999 23:46:26 +0200, Jeroen Ruigrok/Asmodai wrote:
> 
> > If no-one objects I'll submit a manpage per a.out(5) style tomorrow
> > for review untill it's ready for inclusion.
> 
> Anyone who objects to your submissions is a woes -- real bastards wait
> for you to do the work before shooting you down. :-)

Now, that gives me a good feeling =P

I already started work on it...

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: Is the _Device Driver Writers Guide_ still apropos?

[Jeroen Ruigrok/Asmodai]

* Nik Clayton (n...@nothing-going-on.demon.co.uk) [990730 23:37]:
> -hackers,
> 
> Is the FreeBSD Device Driver Writers Guide at
> 
> http://www.freebsd.org/tutorials/ddwg/ddwg.html
> 
> still correct?  I know there have been changes to this area of the tree
> over the past 6 months or so, but I don't know how much of that document
> is still appropriate for what we have now.

As far as I have been able to learn and glance from Bill Paul and some other
device driver guru's too much has changed in order for it to be correct
under CURRENT.

A rewrite is on my to-do list for the PDP, however, should people feel like
they want to rewrite it, be my guest and cc: me on any submissions so I can
include it in the PDP. Else I will start this ASAHP.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: No elf(5) man page (docs/7914)

[Jeroen Ruigrok/Asmodai]

* Nik Clayton (n...@nothing-going-on.demon.co.uk) [990730 23:37]:
> Hi folks,
> 
> We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
> 
> Does anyone feel up to writing one?

Saw it before, noticed it, placed on my to-do list. If no-one objects
I'll submit a manpage per a.out(5) style tomorrow for review untill it's
ready for inclusion.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: Is the _Device Driver Writers Guide_ still apropos?

[Jeroen Ruigrok/Asmodai]

* Nik Clayton ([EMAIL PROTECTED]) [990730 23:37]:
> -hackers,
> 
> Is the FreeBSD Device Driver Writers Guide at
> 
> http://www.freebsd.org/tutorials/ddwg/ddwg.html
> 
> still correct?  I know there have been changes to this area of the tree
> over the past 6 months or so, but I don't know how much of that document
> is still appropriate for what we have now.

As far as I have been able to learn and glance from Bill Paul and some other
device driver guru's too much has changed in order for it to be correct
under CURRENT.

A rewrite is on my to-do list for the PDP, however, should people feel like
they want to rewrite it, be my guest and cc: me on any submissions so I can
include it in the PDP. Else I will start this ASAHP.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: No elf(5) man page (docs/7914)

[Jeroen Ruigrok/Asmodai]

* Nik Clayton ([EMAIL PROTECTED]) [990730 23:37]:
> Hi folks,
> 
> We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
> 
> Does anyone feel up to writing one?

Saw it before, noticed it, placed on my to-do list. If no-one objects
I'll submit a manpage per a.out(5) style tomorrow for review untill it's
ready for inclusion.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Jeroen Ruigrok/Asmodai]

* David Malone (dwmal...@maths.tcd.ie) [990723 18:41]:
> if ((bi->bi_socktype == sep->se_socktype &&
> strcmp(bi->bi_service, sep->se_service) == 0) ||
> matchservent(bi->bi_service, sep->se_service,
> sep->se_proto))
> 
> It should probably say:
> 
> if (bi->bi_socktype == sep->se_socktype &&
> ((strcmp(bi->bi_service, sep->se_service) == 0) ||
> matchservent(bi->bi_service, sep->se_service,
> sep->se_proto)))

Holymoley,

detect the braces-quiz. Those braces which changed are hard to spot, but
prolly mean the world in this case

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Jeroen Ruigrok/Asmodai]

* David Malone ([EMAIL PROTECTED]) [990723 18:41]:
> if ((bi->bi_socktype == sep->se_socktype &&
> strcmp(bi->bi_service, sep->se_service) == 0) ||
> matchservent(bi->bi_service, sep->se_service,
> sep->se_proto))
> 
> It should probably say:
> 
> if (bi->bi_socktype == sep->se_socktype &&
> ((strcmp(bi->bi_service, sep->se_service) == 0) ||
> matchservent(bi->bi_service, sep->se_service,
> sep->se_proto)))

Holymoley,

detect the braces-quiz. Those braces which changed are hard to spot, but
prolly mean the world in this case

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: Will FreeBSD ever see native IPv6 ??

[Jeroen Ruigrok/Asmodai]

* ito...@iijlab.net (ito...@iijlab.net) [990722 16:17]:
> 
> >> Are you just teasing or are you serious?
> >Well, according to what was discussed earlier he is serious. But from
> >prolonged exposure to the kame lists I (think I) know that the FreeBSD ipv6
> >stuff is only available for 3.x and below.
> 
>   We (KAME) are using 3.2-RELEASE and 2.2.8-RELEASE because we can't
>   base our IPv6 development on top of moving target.
>   FreeBSD 3.x-STABLE and 4.x are moving target (which moves very quickly)
>   and are unusable as base version for us - if we need to chase two
>   moving things (IPv6 and FreeBSD) we are doomed.

Problem being is that the 2.2.x branch has been declared obsolete and dead
by the Project.

If serious development work is being done CURRENT has always been the
targetted platform. But let's not nitpick about decissions make months
earlier.

However, 3.2-STABLE isn't that fast moving forward, and I doubt, based on
earlier discussions about touching the 3.x branch, that Jordan will allow
IPv6 to be entered into the 3.x branch (however TPTB may judge otherwise).
So 4.x seems like the only alternative left...

And I am still working on that =)

>   There has been NRL/INRIA/KAME integration work going on (basically
>   to avoid "4 BSDs and 3 IPv6 = 12 choices" nightmare by making one
>   IPv6 stack).  There are, mainly, some (or too many) management
>   issues there.  We will be resolving management issues issue very soon,
>   hopefully by next week.

That's good new ITOJUN-san, but I hope you can understand that after seeing
OpenBSD deploy IPv6 and NetBSD-CURRENT getting the IPv6 code merged by you,
that FreeBSD (read the userbase/developers) is anxious to also incorporate
this.

>   There's incomplete "unified" codebase there, which is not very
>   ready for public consumption.  Anyway please hold till the managment
>   issue is resolved, I believe I can give you a good news.

Let me ask one question: if a few of us got the 3.x kit of kame up to 4.x
level and it got all commited would it make the `merged' stack easier to
integrate into CURRENT or does the stack-project prefer to use a clean
codebase? I myself think the first, which allows our driver writers time
to adjust to IPv6 changes, get a lot of still-present bugs out and basically
restabilize the system before the next IPv6 changes. Not to mention allow
people to test/work with IPv6 already.

I would love to hear your reactions to the above,

kind regards,

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: Will FreeBSD ever see native IPv6 ??

[Jeroen Ruigrok/Asmodai]

* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [990722 16:17]:
> 
> >> Are you just teasing or are you serious?
> >Well, according to what was discussed earlier he is serious. But from
> >prolonged exposure to the kame lists I (think I) know that the FreeBSD ipv6
> >stuff is only available for 3.x and below.
> 
>   We (KAME) are using 3.2-RELEASE and 2.2.8-RELEASE because we can't
>   base our IPv6 development on top of moving target.
>   FreeBSD 3.x-STABLE and 4.x are moving target (which moves very quickly)
>   and are unusable as base version for us - if we need to chase two
>   moving things (IPv6 and FreeBSD) we are doomed.

Problem being is that the 2.2.x branch has been declared obsolete and dead
by the Project.

If serious development work is being done CURRENT has always been the
targetted platform. But let's not nitpick about decissions make months
earlier.

However, 3.2-STABLE isn't that fast moving forward, and I doubt, based on
earlier discussions about touching the 3.x branch, that Jordan will allow
IPv6 to be entered into the 3.x branch (however TPTB may judge otherwise).
So 4.x seems like the only alternative left...

And I am still working on that =)

>   There has been NRL/INRIA/KAME integration work going on (basically
>   to avoid "4 BSDs and 3 IPv6 = 12 choices" nightmare by making one
>   IPv6 stack).  There are, mainly, some (or too many) management
>   issues there.  We will be resolving management issues issue very soon,
>   hopefully by next week.

That's good new ITOJUN-san, but I hope you can understand that after seeing
OpenBSD deploy IPv6 and NetBSD-CURRENT getting the IPv6 code merged by you,
that FreeBSD (read the userbase/developers) is anxious to also incorporate
this.

>   There's incomplete "unified" codebase there, which is not very
>   ready for public consumption.  Anyway please hold till the managment
>   issue is resolved, I believe I can give you a good news.

Let me ask one question: if a few of us got the 3.x kit of kame up to 4.x
level and it got all commited would it make the `merged' stack easier to
integrate into CURRENT or does the stack-project prefer to use a clean
codebase? I myself think the first, which allows our driver writers time
to adjust to IPv6 changes, get a lot of still-present bugs out and basically
restabilize the system before the next IPv6 changes. Not to mention allow
people to test/work with IPv6 already.

I would love to hear your reactions to the above,

kind regards,

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: Will FreeBSD ever see native IPv6 ??

[Jeroen Ruigrok/Asmodai]

* John Hay (j...@mikom.csir.co.za) [990722 11:55]:
> Are you just teasing or are you serious?

Well, according to what was discussed earlier he is serious. But from
prolonged exposure to the kame lists I (think I) know that the FreeBSD ipv6
stuff is only available for 3.x and below.

> I searched through their site (again), but except for being mentioned
> in their TODO for the past few months, I can't find anything that
> indicates that they or anyone else is working on it. They may be, but
> it isn't visible anywhere where I have looked. It would be nice if
> there was some place to follow their progress, because I'm also one
> of the people that would like to see IPv6 integrated into FreeBSD.

At the moment I am busy merging ipv6 from the 3.x kit into CURRENT, but
I have to see how to spread my time because I am also doing work on OVCS,
the PDP and some other projects. *bwerk* days are much too short...

If anyone else is having some spare time and willing to mess with the
kame 3.x kit cvsup stuff and CURRENT alongside me, please drop a mail.

'gards,

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: Will FreeBSD ever see native IPv6 ??

[Jeroen Ruigrok/Asmodai]

* John Hay ([EMAIL PROTECTED]) [990722 11:55]:
> Are you just teasing or are you serious?

Well, according to what was discussed earlier he is serious. But from
prolonged exposure to the kame lists I (think I) know that the FreeBSD ipv6
stuff is only available for 3.x and below.

> I searched through their site (again), but except for being mentioned
> in their TODO for the past few months, I can't find anything that
> indicates that they or anyone else is working on it. They may be, but
> it isn't visible anywhere where I have looked. It would be nice if
> there was some place to follow their progress, because I'm also one
> of the people that would like to see IPv6 integrated into FreeBSD.

At the moment I am busy merging ipv6 from the 3.x kit into CURRENT, but
I have to see how to spread my time because I am also doing work on OVCS,
the PDP and some other projects. *bwerk* days are much too short...

If anyone else is having some spare time and willing to mess with the
kame 3.x kit cvsup stuff and CURRENT alongside me, please drop a mail.

'gards,

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: building thread-safe Xlibs

[Jeroen Ruigrok/Asmodai]

* Francis Jordan ([EMAIL PROTECTED]) [990626 06:03]:
>  xc/include/Xos_r.h
> 
> which contains definitions of same (basically, pwd.h wrappers) for various 
> platforms, but not FreeBSD (I guess at the time FreeBSD didn't have threads). 
> Unfortunately, the wrappers for other platforms are no good, as FreeBSD's pwd
> structures are different from everything else.

Hmmm, one thing that's still missing from at least the POSIX threads is
pthread_cancel. Plus that there's no such thing as a libpthread.

Thread support (POSIX) has a long way to come in FreeBSD, but I lack
the cloo-by-four to do it.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security Specialist   BSD: Technical excellence at it's best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: building thread-safe Xlibs

[Jeroen Ruigrok/Asmodai]

* Francis Jordan (fran...@netscape.net) [990626 06:03]:
>  xc/include/Xos_r.h
> 
> which contains definitions of same (basically, pwd.h wrappers) for various 
> platforms, but not FreeBSD (I guess at the time FreeBSD didn't have threads). 
> Unfortunately, the wrappers for other platforms are no good, as FreeBSD's pwd
> structures are different from everything else.

Hmmm, one thing that's still missing from at least the POSIX threads is
pthread_cancel. Plus that there's no such thing as a libpthread.

Thread support (POSIX) has a long way to come in FreeBSD, but I lack
the cloo-by-four to do it.

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security Specialist   BSD: Technical excellence at it's best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


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

Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)

[Jeroen Ruigrok/Asmodai]

* Warner Losh (i...@harmony.village.org) [990623 07:43]:
> daemon.ninth-circle.org> Jeroen Ruigrok/Asmodai writes:
> : Granted, we can never think of reaching a commercial level on documentating
> : the internals/code which all the committers provide. 
> 
> I think that the documenation that Doug has written to date EXCEEDS so
> called commercial standards.

Then I am happy to change to all to most from the above sentence (which
ought to have been most up there from the first).

-- 
Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl
The *BSD Programmer's Documentation Project 
Network/Security Specialist  <http://home.wxs.nl/~asmodai>
*BSD: We are back and will not accept no...


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

Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)

[Jeroen Ruigrok/Asmodai]

* Warner Losh (i...@harmony.village.org) [990623 07:43]:
> @daemon.ninth-circle.org> Jeroen Ruigrok/Asmodai writes:
> : No documentation is worse than just a sparse manpage.
> 
> ls /usr/share/man/man9 | egrep 

Oh, I wasn't implying that the newbus guys didn't document anything. I was
merely commenting in a more general sense, but my timing within the thread
might have given the idea it was said within the context of the newbus
discussion/talks.

Apologies if people thought so, but I thought I was careful enough to
generalise it.

-- 
Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl
The *BSD Programmer's Documentation Project 
Network/Security Specialist  <http://home.wxs.nl/~asmodai>
*BSD: We are back and will not accept no...


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

Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)

[Jeroen Ruigrok/Asmodai]

* Mike Smith (m...@smith.net.au) [990622 17:38]:
> > And they might, too.  phk has frequently expressed a desire to either
> > write documentation on existing systems, or at least help others do
> > so.
> 
> No offence meant, but we can see how much of this has actually 
> materialised.

Hence I started the PDP =P

Still going strong...

> > > Documentation is written after the fact, by someone else.
> > 
> > That's the worst kind of documentation.  In fact, most UNIX
> > documentation is written by the authors.  After the fact, admittedly.
> 
> In fact, most Unix documentation is never written, being my original 
> point.

Which sucks given all the crap the same people tend to spew then about 
Microsoft being very closed about their internals.

No documentation is worse than just a sparse manpage. The latter at least
makes it more understanding for all without doing too much UTSL.
And given the aspirations the Project has with regard to commercial support
I find the silent encouragement of just hack and not document disturbing
to say the very least.

> As always, complaining about the _lack_ of something is the wrong 
> approach for this project.  Step up and fill the gap, or expose 
> yourself to criticism for failing to do so.  There has to be a way to 
> make a verb from Brett Glass' name, but I'm sure you get the point.

And I did/am doing that with the PDP, which at it current rate of support
(that is just me ;) whill be finished somewhere when FreeBSD 6.5 will be
released or so, but I am not complaining about that =)

I am not fingerpointing here, not am I willing to. I just want to ask all
developers to try and document at least the basic ideas somewhere in a 
manpage in order to make it easier for others (like me) who want to get
the documentation on the road.

Thanks,

-- 
Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl
The *BSD Programmer's Documentation Project 
Network/Security Specialist  
*BSD: We are back and will not accept no...


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

Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)

[Jeroen Ruigrok/Asmodai]

* Mark Newton (new...@internode.com.au) [990622 17:38]:
> Hellmuth Michaelis wrote:
> 
>  > > And as to the author: Writing docu while you are implementing something
>  > > might work in a commercial environment where you want to be able to
>  > > market something before it's sell-by date, but for hobbiests who
>  > > basically spend the odd evening doing something, it is too much hassle.
>  > 
>  > In case FreeBSD wants to enter commercial environments, we have to behave
>  > like behaving in commercial environments.
>  
> Ok, so let's follow Microsoft's industry-leading documentation standards.

Blah, this argument is, pardon my french, utter bullshit.

If one looks at, the now deceased, DEC Unix and it's programmer's manuals, ye
see what Hellmuth tries to put down with his statement. In fact I have a 
couple of those pdf/ps files printed out and they make for TOP CLASS
programmer's material. Needless to say I hope to reach this level of 
excellence with the PDP as well...

It's all a matter of time and effort and unfortunately not many care to take
the time to document, but rather hack on. (And somewhere that's very 
understandable.)

-- 
Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl
The *BSD Programmer's Documentation Project 
Network/Security Specialist  
*BSD: We are back and will not accept no...


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

Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)

[Jeroen Ruigrok/Asmodai]

* Doug Rabson (d...@nlsystems.com) [990622 20:48]:
> On Tue, 22 Jun 1999, Hellmuth Michaelis wrote:
> 
> > >From the keyboard of Nick Hibma:
> > 
> > > And as to the author: Writing docu while you are implementing something
> > > might work in a commercial environment where you want to be able to
> > > market something before it's sell-by date, but for hobbiests who
> > > basically spend the odd evening doing something, it is too much hassle.
> > 
> > In case FreeBSD wants to enter commercial environments, we have to behave
> > like behaving in commercial environments.
> > 
> > I know that it is current behaviour, much easier and obviously a commonly
> > accepted thing that code, subsystem and/or changes are not and need not
> > to be documented, but this is not a reason in itself for not changing this.
> > 
> > Also, i think that the argument Mike and others use: "don't complain for a 
> > lack of things, contribute!" - which i use and used all the time - is not
> > valid for this issue: at least i can't contribute because i don't understand
> > things (now someone could argue, that i'm wrong here ...).
> 
> Writing software in one's spare time is a case of triage. When I have a
> day or two to spend working on FreeBSD, I have to make a choice on what
> most needs doing and if that is a choice between technical writing or
> designing an algorithm to fix the current limitations of driver detach and
> KLD unload, I don't think the technical writing is going to win.

I can perfectly understand that, and I like to fill that gap. The gap being
the lack of documentation.

Granted, we can never think of reaching a commercial level on documentating
the internals/code which all the committers provide. To think that is either
dreaming far into the future or just being foolish. However there is a 
certain amount of documentation that can be done, skeletal manpages, good
sourcecode comments, and the likes that make filling in the abovementioned
gap easier for those who (are willing and) have the time to do this.

> People must also bear in mind that the most important target release for
> this software is 4.0 which isn't scheduled until next year. I am certain
> that the documentation situation will improve before that release.

It is already getting improved upon Doug.

And as a sidenote, so is asking feedback for pr's what Sheldon is doing a 
lot and which I tend to assist him in.

-- 
Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl
The *BSD Programmer's Documentation Project 
Network/Security Specialist  
*BSD: We are back and will not accept no...


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

Re: libss

[Jeroen Ruigrok/Asmodai]

* David O'Brien (obr...@nuxi.com) [990621 10:38]:
> Does anybody know what /usr/src/lib/libss/ is?  There isn't a manpage for
> it, and viewing the source I still can't figure out what it is other than
> it came from MIT (Athena).

Apparantly David it came from the SIPB at MIT and more specifically as 
part of security/encryption studies as far as I have been able to glance
from the files both locally and at MIT.

They oughtta be shot/hanged or whatnot for the lack of commentary in the
sourcecode... Man, it makes one wonder whether or not they get a curriculum
about lack of documenting =)

Apparantly the libss is also used a lot for a project called Zephyr at MIT.
And what I gather from the (sparse) docs libss and libet are replacements
for athena.

Hope this is of some help...

-- 
Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl
The *BSD Programmer's Documentation Project 
Network/Security Specialist  
*BSD: We are back and will not accept no...


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

A question about errors.

[Jeroen Ruigrok/Asmodai]

Hi,

I am updating the description of intro(3) and have stumbled upon some
challenges:

#define EAUTH   80  /* Authentication error */
#define ENEEDAUTH   81  /* Need authenticator */
#define EOVERFLOW   84  /* Value too large to be stored in
data type */
#define ECANCELED   85  /* Operation canceled */

I think I know what EOVERFLOW does, if one tries to put a certain number in
an int declared variable which is greater than int can take it will
generate an EOVERFLOW.

Is EAUTH a basic uid<>password authentication failure, or is it broader
or..?

ECANCELED? Is this our basic CTRL-C?

Thanks for any explanations on this part =)

'gards,

---
Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl
The FreeBSD Programmer's Documentation Project 
Network/Security Specialist  
*BSD: Accept no limitations...


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

freebsd-hackers@freebsd.org

[Jeroen Ruigrok/Asmodai]

On 24-May-99 Stephen Hocking-Senior Programmer PGS Tensor Perth wrote:
> 
> I'm hunting around for a list of entry points in both Linux & FreeBSD's
> libc. I want to find out what linux libc entry points are not found
> within the BSD libc, and what entry points that are common have different
> arguments be they just different or things of the same name with different
> definitions.
> 
> This is so a shim library can be developed allowing the use of Linux
> libraries liked into FreeBSD binaries. I am anticipating that perhaps the
> Linux lib may have to be altered in some way (changing the name of an
> external reference where it clashes with a FreeBSD libc call of the same
> name with varying arguments, or mapping external variables onto their
> FreeBSD equivalents). It'll make the use of certain recalcitrant third
> party libs a bunch easier.

Well, there's work underway to document the NetBSD/FreeBSD sources wrt to
functions, system calls, etc... See some of that stuff at my homepage (URL
in .sig) and look for the PDP link.

Should you receive additional information, please keep me informed so I can
expand the list.

'gards,

---
Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl
The FreeBSD Programmer's Documentation Project 
Network/Security Specialist  
*BSD: Accept no limitations...


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

RE: security: what does OpenBSD have, that FreeBSD doesn't have.

[Jeroen Ruigrok/Asmodai]

On 23-May-99 sth...@nethelp.no wrote:
>> The OpenBSD team does a lot wrt auditing of the complete sourcetree, but
>> then the question is: is this valid concern or is this pure paranoia.
>> OpenBSD does a lot of valid changes but borders (and sometimes crosses
>> that border) on paranoia, wrt code.
> 
> Given the number of postings to BUGTRAQ about array overflows and stack
> smashing, I think it's relevant to ask whether it possible to be *too*
> paranoid here. Personally, I think what the OpenBSD folks are doing is
> very important.

Paranoia/security and freedom of use are opposites on the balance of use.
If you make so much security restrictions to a system it's bound to make it
less enjoyable where it concerns freedom.

>> A lot of the security tools can be get from the ports, but the true
>> security of a system lies in the eye of the admin. I have known admins
>> whom I would never trust mission critical security systems to.
> 
> "The true security of a system" depends on the operating system itself,
> the applications, *and* the admin. You can be a very good and security
> conscious admin - but it won't help you much if the operating system is
> Windows 98.

Correct there Steinaur, I left those other two out. But then the admin most
certainly knows that he has to replace that Win98 box with FreeBSD ;)

---
Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl
The FreeBSD Programmer's Documentation Project 
Network/Security Specialist  
*BSD: Accept no limitations...


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

RE: IPv6 and -current?

[Jeroen Ruigrok/Asmodai]

On 23-May-99 Alex Zepeda wrote:
> Out of a perhaps morbid curiosity, I'm somewhat interested in setting up
> an IPv6 stack on my computer.  From what I can tell there are two well
> supported stacks.  Kame and Inria, and both support 2.2.8, Kame also
> supports 3.x.  Has anyone tried to port either to -current?  I tried
> playing around with the Kame release for 3.0, and it generated quite a
> few rejects...

I am currently merging KAME with CURRENT and it's a lovely adventure to
embark on...

One can best port 3.x to CURRENT since the internal changes from 2.2.x to
3.x are great and would merely duplicate work...

If yer interested Alex, we could work together on this and prepare a
CURRENT-KAME solution since I believe the time has come to start work in
CURRENT on IPv6. 

I already mailed Itojun-san about the status of the KAME/Inria merger and
hope to hear from him soon.

HTH,

---
Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl
The FreeBSD Programmer's Documentation Project 
Network/Security Specialist  
*BSD: Accept no limitations...


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

RE: security: what does OpenBSD have, that FreeBSD doesn't have.

[Jeroen Ruigrok/Asmodai]

Hi Andreas =)

On 23-May-99 Andreas Klemm wrote:
> Am currently discussing FreeBSD vs. OpenBSD in private e-mail.
> 
> What make OpenBSD so "secure" ? Or can this kind of security be
> reproduced with FreeBSD ports ? I think of tools like:

Ye missed one of the most important things: auditing of the sourcecode.

The OpenBSD team does a lot wrt auditing of the complete sourcetree, but
then the question is: is this valid concern or is this pure paranoia.
OpenBSD does a lot of valid changes but borders (and sometimes crosses thta
border) on paranoia, wrt code.

A lot of the security tools can be get from the ports, but the true
security of a system lies in the eye of the admin. I have known admins whom
I would never trust mission critical security systems to.

HTH,

---
Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl
The FreeBSD Programmer's Documentation Project 
Network/Security Specialist  
*BSD: Accept no limitations...


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

RE: Logging "promiscuous mode disabled"

[Jeroen Ruigrok/Asmodai]

On 22-May-99 Sheldon Hearn wrote:

> It doesn't seem to me like it'd break anything, and I'd like to know
> for sure when it's turned off -- it'd mean I don't have to count up the
> number of "promiscous mode enabled" messages and make sure that that
> number matches the number of applications I've run and subsequently
> terminated.

Sounds like a good idea to me Sheldon...

Would make intrusion detection easier, etc etc =)

---
Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl
The FreeBSD Programmer's Documentation Project 
Network/Security Specialist  
*BSD: Accept no limitations...


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

FW: Question on rename()

[Jeroen Ruigrok/Asmodai]

Could you guys please give yer own opinions on that?
I will compile some of the better arguments and resend them to the Posix
revision list...

-FW: <990518120639.zm1...@tamarix.rdg.opengroup.org>-

Date: Tue, 18 May 1999 13:06:40 +0100
From: Andrew Josey 
To: austin-gr...@opengroup.org
Subject: Question on rename()

All,
The following question was raised to my attention. I'd appreciate
thoughts on this and recommendations on the next step
best regards
Andrew

--- Forwarded mail

In POSIX 1003.1 1996 in 5.5.3.2 there is the rather unfortunate
part "If the old argument and the new argument both refer to
links to the same existing file, the rename() function shall
return successfully and perform no other action.".

In SUSV2 it is stated that
"If the old argument and the new argument both refer to,
and both link to the same existing file, rename() returns
successfully and performs no other action."

People are quite bothered by the fact that the Linux kernel
follows this, possibly too literally. One consequence is
that after a successful
rename("aa", "bb");
it is possible that aa still exists, i.e., that
stat("aa", &buf);
still succeeds. Another is that on a filesystem where
filenames are case-sensitive upon readdir() and creat()
but case-insensitive for open(), it may be impossible
to do
rename("austin","Austin");
and
rename("austin","aux"); rename("aux","Austin");
would be required.

The rationale does not mention such strange cases
and just says that the sentence is meant to ensure
that
rename("x", "x");
does not remove the file x.
--


---End of forwarded mail

-
Andrew JoseyThe Open Group
Austin Group Chair  Apex Plaza,Forbury Road,
Email: a.jo...@opengroup.orgReading,Berks.RG1 1AX,England
Tel:   +44 118 9508311 ext 2250 Fax: +44 118 9500110

--End of forwarded message-

---
Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl
The FreeBSD Programmer's Documentation Project 
Network/Security Specialist  
*BSD: Accept no limitations...


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