Re: readdirplus is very cool, any other nfs client suggestions?

[Dag-Erling Smorgrav]

Alfred Perlstein  writes:
> DES: can you elaborate?  you think it may cause problems with amd
> since it's like an NFS buffer isn't it and would work over the 
> loopback...

I used loopback mounts to test NFS make worlds a while ago (there were
places where make world would bomb because chflags doesn't work on
NFS) and experienced deadlock problems. Somebody (I don't remember who
exactly) told me that this was a known problem with the NFSv3 code;
reading over loopback mounts works fine, but writing apparently
results in deadlocks. Search the archives; the commit logs should give
you an idea of when this was (check the logs for Makefiles that use
chflags).

r...@des ~# current -l -F Makefile chflags 
src/Makefile.inc1
src/lib/libc/sys/Makefile.inc
src/lib/libc_r/Makefile
src/release/Makefile
src/sys/alpha/conf/Makefile.alpha
src/sys/i386/conf/Makefile.i386
src/sys/pc98/conf/Makefile.pc98
src/usr.bin/Makefile
src/usr.bin/chflags/Makefile
src/usr.bin/chpass/Makefile
src/usr.bin/passwd/Makefile

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


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

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

John-Mark Gurney  writes:
> Sheldon Hearn scribbled this message on Aug 1:
> > Would you need these entries if inetd let you specify port numbers
> > instead of service names?
> I vote for allowing inetd.conf to specify a port number instead of a
> service name...  it should be very easy to make the modification, and
> I'm willing to do all the work, assuming no one on -committers objects..

The correct way to do this is to fix getservbyname() so it accepts
port numbers.

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


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

confusion about nfsm_srvmtofh bad behavior?

[Alfred Perlstein]

ok:

#define nfsm_srvmtofh(f) \
{ int fhlen = NFSX_V3FH; \
if (nfsd->nd_flag & ND_NFSV3) { \
nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
fhlen = fxdr_unsigned(int, *tl); \
if (fhlen == 0) { \
bzero((caddr_t)(f), NFSX_V3FH); \
} else if (fhlen != NFSX_V3FH) { \
error = EBADRPC; \
nfsm_reply(0); \
} \
} \
if (fhlen != 0) { \
nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
if ((nfsd->nd_flag & ND_NFSV3) == 0) \
nfsm_adv(NFSX_V2FH - NFSX_V3FH); \
} \
}

notice the bcopy?  i don't really understand why we always
seem to copy 64 bytes (NFSX_V3FH), isn't this a bug?

NFSX_V3FH is 64 right?

my understanding of the code is as follows:

---
fhlen set to 64,

if we are using NFS3, extract the size of the handle from the mbufs
  if it's not valid abort with an error

now advance to the data portion (the filehandle)

copy it into the file handle, but copy 64 bytes regardless
  of the value of 'fhlen', in fact if we are using NFSv2 then
  it should only copy 32 bytes no?

it then rewinds the mbuf pointers (i think) because of the
  over "dissection" above.
---

why does it do the copy, then rewind it, it seems like it knows
it's doing something wrong and instead of fixing it, it just 
compensates after the fact.


it would have been nice if some of the variables used here
were more than 3 charaters and there was a comment or two
sprinkled about.

the code is actually pretty nifty and makes sense, but you need
to stare at it for a few hours before you can make heads or
tails of anything.  the fact that nested macros used modify
variables in the calling function is really, urm... cool? :)


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



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

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On 02 Aug 1999 13:05:17 +0200, Dag-Erling Smorgrav wrote:

> The correct way to do this is to fix getservbyname() so it accepts
> port numbers.

Would this not still require modifications to /etc/services for services
not already mentioned in that file?

Ciao,
Sheldon.


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

Re: Proposing argv for klds and preloaded modules

[Boris Popov]

On Sun, 1 Aug 1999, Chris Costello wrote:

> On Sun, Aug 01, 1999, Juha Nurmela wrote:
> >
> > Sometimes it would be handy to pass a commandline
> > to a kld, preloaded modules already support
> > arguments. kldload(2) unfortunately has only
> > the pathname.ko argument.
> 
>Is this really a problem?  Can the administrator not use
> sysctl instead?

It is not always possible. Some device drivers (both hardware and
software) require an arguments that needed at init/attach time.

IMO, args should be passed in usual manner via argv[] and
argc with plain get_opt() in libkern.

--
Boris Popov
http://www.butya.kz/~bp/



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

Re: Mentioning RFC numbers in /etc/services

[Daniel Eischen]

Dag-Erling Smorgrav wrote:
> John-Mark Gurney  writes:
> > Sheldon Hearn scribbled this message on Aug 1:
> > > Would you need these entries if inetd let you specify port numbers
> > > instead of service names?
> > I vote for allowing inetd.conf to specify a port number instead of a
> > service name...  it should be very easy to make the modification, and
> > I'm willing to do all the work, assuming no one on -committers objects..
> 
> The correct way to do this is to fix getservbyname() so it accepts
> port numbers.

Are you sure this is what you want?  It may allow an application to
use a port number that would otherwise be invalid.

Dan Eischen
eisc...@vigrid.com


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

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

Sheldon Hearn  writes:
> On 02 Aug 1999 13:05:17 +0200, Dag-Erling Smorgrav wrote:
> > The correct way to do this is to fix getservbyname() so it accepts
> > port numbers.
> Would this not still require modifications to /etc/services for services
> not already mentioned in that file?

Allow me to re-quote the message I answered:

> I vote for allowing inetd.conf to specify a port number instead of a
> service name...

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


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

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On 02 Aug 1999 13:19:01 +0200, Dag-Erling Smorgrav wrote:

> > Would this not still require modifications to /etc/services for services
> > not already mentioned in that file?
> 
> Allow me to re-quote the message I answered:
> 
> > I vote for allowing inetd.conf to specify a port number instead of a
> > service name...

I think that's exactly what Daniel's getting at.

If we fix this in inetd, we get what we want. If we fix this in
getservbyport() we may get something that we don't want, namely
applications that relay on the existing behaviour of the function stop
working as intended.

Ciao,
Sheldon.


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

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

Daniel Eischen  writes:
> Dag-Erling Smorgrav wrote:
> > The correct way to do this is to fix getservbyname() so it accepts
> > port numbers.
> Are you sure this is what you want?

Yes.

>  It may allow an application to
> use a port number that would otherwise be invalid.

Please elaborate.

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


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

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On Sat, 31 Jul 1999 23:00:15 MST, Doug wrote:

> > Would you need these entries if inetd let you specify port numbers
> > instead of service names?
>
>   Errr... while that may be of value to someone, it has nothing to
> do with the issue Ben and I were discussing.

Yes yes. I'm not trying to contribute to the conversation you're having.
I'm trying to get your opinion on an issue that came up during your
conversation. :-)

Ciao,
Sheldon.


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

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On 02 Aug 1999 13:27:44 +0200, Dag-Erling Smorgrav wrote:

> I don't see in what way an application could break if getservbyname()
> suddenly accepted numeric port specifications. It won't ``stop working
> as intended'', it'll keep on working as it always used to, plus a
> little more.

My application limits the port numbers it'll play with based on what's
in /etc/services, since getservbyname() implies this limitation.

Administrators rely on the fact that only root can play with
/etc/services so that this silly application can't play with ports that
aren't in that file.

No getservbyname() doesn't work the way it used to, and the
administrator is shot in the foot, even though he didn't pull the
trigger.

Ciao,
Sheldon.


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

Re: Mentioning RFC numbers in /etc/services

[Daniel Eischen]

Dag-Erling Smorgrav wrote:
> >  It may allow an application to
> > use a port number that would otherwise be invalid.
>
> Please elaborate.

I don't have any specific applications in mind :)  But suppose an
application (for whatever reason) only wants to allow selection of
certain service names.  A user could type in any port number that
was in /etc/services, and the application would use it.

Are you also going to allow getservbyport to lookup names?

Dan Eischen
eisc...@vigrid.com


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

Re: confusion about nfsm_srvmtofh bad behavior?

[Alfred Perlstein]

On Mon, 2 Aug 1999, Alfred Perlstein wrote:

>   } \
>   if (fhlen != 0) { \
>   nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
>   bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
>   if ((nfsd->nd_flag & ND_NFSV3) == 0) \
>   nfsm_adv(NFSX_V2FH - NFSX_V3FH); \
>   } \
>   }

...

> it then rewinds the mbuf pointers (i think) because of the
>   over "dissection" above.
> ---
> 
> why does it do the copy, then rewind it, it seems like it knows
> it's doing something wrong and instead of fixing it, it just 
> compensates after the fact.

yes, replying to my own message.

the only thing i can think of is that the extra data is safely
ignored because the routines that use these macros seem to
pass the version of NFS to all the function that they call...

however unless i'm wrong (which i probably am) nfsV2 stuff
could be made faster if it was correctly noted and less data
was copied.  It would also DTRT and not access data it isn't
supposed to :)

it seems like all of the V3 handles are the same length so
there isn't much to do there...

-Alfred



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

Re: Mentioning RFC numbers in /etc/services

[Daniel Eischen]

Daniel Eischen wrote:
> Are you also going to allow getservbyport to lookup names?   

Stupid question.  This isn't possible since getservbyport takes
an int argument.

Dan Eischen
eisc...@vigrid.com


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

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On Mon, 02 Aug 1999 07:30:32 -0400, Daniel Eischen wrote:

> Are you also going to allow getservbyport to lookup names?

And how are you going to squish a name into an int? :-)

Ciao,
Sheldon.


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

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

Sheldon Hearn  writes:
> If we fix this in inetd, we get what we want. If we fix this in
> getservbyport() we may get something that we don't want, namely
> applications that relay on the existing behaviour of the function stop
> working as intended.

I don't see in what way an application could break if getservbyname()
suddenly accepted numeric port specifications. It won't ``stop working
as intended'', it'll keep on working as it always used to, plus a
little more. It'll also make it a darn sight easier to parse port
specifications e.g. from the command line.

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


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

A Proposal for a Consumers' Private Network with Providers

[Richard Auld]

Aug. 2, 1999.

Dear Sir or Ms:

This notification is being sent to a selected group of consumer-oriented 
organizations and individuals that I believe will be interested, and that I 
hope can help with advice on how best to proceed with a proposal that I feel 
certain can be of very great benefit to consumers world wide.

The proposal is covered in some detail on a Web site that has recently been 
posted, and which has not yet been promoted in the normal ways, so only the 
recipients of this notification should be aware of it's existence at this 
point.  Briefly, the proposal is for a Virtual Private Network, to be composed 
of a world wide Extranet that links many small local area Intranets (e.g., 
USA=47,000 zipcode areas, max.) to be owned and operated by consumer co-ops.  
The Extranet would be operated by a world wide Federation of these local area 
co-ops.

The benefits for the members of these co-ops would be numerous, and 
non-member consumers would benefit also, in accordance with co-op traditions.  
The Web site describes the origins of these benefits in some detail.

My primary concern at this point is how best to proceed for the good of all 
consumers.  I am a retired business systems analyst and programmer, not an 
experienced cooperative business developer, and I especially want to avoid 
inadvertently doing anything that might jeopardize a major cause for which I am 
proposing this network ~ that of a world wide Federation of consumer co-ops.

   I firmly believe that, for reasons both technical and otherwise, now is the 
time for this proposal to be implemented.  I believe I am competent to 
undertake the direction of many of the software development tasks that would be 
required to implement this network, but beyond that narrowly technical area, I 
am in the learning mode, at best, especially regarding the financial/legal 
issues and options involved.

So, if you and your associates feel that this proposal has at least some of 
the outstanding merit that I claim for it in the book-format Web site, I would 
be both open to and very appreciative of suggestions and/or business proposals 
as to how best to proceed with it's development, including any design revisions 
that you may deem advisable.  Please consider the rather amateurish business 
development plans mentioned in the proposal as separate from the proposed 
network and software design concepts, which I now believe to be both 
technically feasible and to have at least  adequate functionality, at least for 
discussion and detailed improvements, if not for actual network startup 
purposes.

The Web site is accessible from my Netopia virtual office by simply 
selecting "Wisdom, Inc." on the "office door".  You will also notice on the 
office door there a diagram of the proposed network architecture.  That diagram 
and it's accompanying text is the first slide of a presentation that was 
prepared for consumers in general, and the remainder of the show is accessed by 
selecting the "Pictures" button to the upper left.  The help facility shows 
fairly complete instructions, but if you have any questions or wish to speak to 
me personally, please contact me at any time by selecting "Conference" ~ the 
"Intercom" is an internet telephone.  Text chat and MS NetMeeting-compatible 
group interactions are facilitated in the conference room also.

Thank You for your help!

CLICK Here to visit my Netopia Virtual Office

   Co-operatively Yours,

   Richard J. Auld

3421 Ivanhoe Lane

Garland, TX 75044

972-414-0295 

 

<><>

Re: Mentioning RFC numbers in /etc/services

[Matthew Dillon]

:John-Mark Gurney  writes:
:> Sheldon Hearn scribbled this message on Aug 1:
:> > Would you need these entries if inetd let you specify port numbers
:> > instead of service names?
:> I vote for allowing inetd.conf to specify a port number instead of a
:> service name...  it should be very easy to make the modification, and
:> I'm willing to do all the work, assuming no one on -committers objects..
:
:The correct way to do this is to fix getservbyname() so it accepts
:port numbers.
:
:DES
:-- 
:Dag-Erling Smorgrav - d...@flood.ping.uio.no

If we were to depend on this, it would break code compatibility with 
other UNIXes for no good reason.   For example, someone porting inetd
from FreeBSD to something else would not get a compatible result without
undoing the 'fix'.

'Fixing' getservbyname() is a really bad idea.

-Matt
Matthew Dillon 



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

Re: So, back on the topic of enabling bpf in GENERIC...

[Josef Karthauser]

On Sun, Aug 01, 1999 at 10:17:54AM -0400, Sergey Babkin wrote:
> Warner Losh wrote:
> > 
> > In message <37a3b701.851df...@softweyr.com> Wes Peters writes:
> > : Do we have a list of all services that use bpf?  I'm willing to edit the 
> > man
> > : pages, given a list.  I guess I could just grep-o-matic here, huh?
> > 
> > Yes.  I'm also in a holding off pattern until we know the exact impact
> > for all daemons that use this...
> 
> I think I found a solution that may be better (although more complicated):
> 
> Let the sysadmin to define a bpf filter for the packets that are considered
> OK (say, DHCP or RARP or RBOOT or whatever else this installation needs for
> normal functioning). Provide some typical examples.
> 
> After this filter is defined and the system goes to a higher security
> level bpf first applies this filter to all the incoming packets, and only
> if they pass this filter they are checked for application-specified filters.
> If there is no such "master" filter defined then bpf can just deny
> new open()s as proposed earlier. This will allow the applications to 
> use bpf but only for the purposes defined in the master filter. This 
> also resolves the problem of services re-opening bpf after SIGHUP.
> 

I like this.  I'd prefer the default to be that bpf forwards all
packets, unless there is a template filter defined.  I see no reason
to change access to bpf at higher secure levels, because a master
filter can be installed at boot time to do this work.  Of course
we may have an equivalent of 'IPFIREWALL_DEFAULT_TO_ACCEPT' to
accomodate this.

Joe
-- 
Josef KarthauserFreeBSD: How many times have you booted today?
Technical Manager   Viagra for your server (http://www.uk.freebsd.org)
Pavilion Internet plc.  [...@pavilion.net, j...@uk.freebsd.org, j...@tao.org.uk]


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

Re: readdirplus is very cool, any other nfs client suggestions?

[Matthew Dillon]

:Alfred Perlstein  writes:
:> DES: can you elaborate?  you think it may cause problems with amd
:> since it's like an NFS buffer isn't it and would work over the 
:> loopback...
:
:I used loopback mounts to test NFS make worlds a while ago (there were
:places where make world would bomb because chflags doesn't work on
:NFS) and experienced deadlock problems. Somebody (I don't remember who
:exactly) told me that this was a known problem with the NFSv3 code;
:reading over loopback mounts works fine, but writing apparently
:results in deadlocks. Search the archives; the commit logs should give
:you an idea of when this was (check the logs for Makefiles that use
:chflags).
:
:r...@des ~# current -l -F Makefile chflags 
:src/Makefile.inc1
:src/lib/libc/sys/Makefile.inc
:src/lib/libc_r/Makefile
:src/release/Makefile
:src/sys/alpha/conf/Makefile.alpha
:src/sys/i386/conf/Makefile.i386
:src/sys/pc98/conf/Makefile.pc98
:src/usr.bin/Makefile
:src/usr.bin/chflags/Makefile
:src/usr.bin/chpass/Makefile
:src/usr.bin/passwd/Makefile
:
:DES
:-- 
:Dag-Erling Smorgrav - d...@yes.no

The buildworld chflags problems were fixed around a month ago I think.
Since then there have been many NFS fixes committed.  I have not tested
running buildworld over a loopbacked NFS mount -- I'll do that today --
but I'd say there is a good chance that it will simply work.

-Matt
Matthew Dillon 



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

Re: confusion about nfsm_srvmtofh bad behavior?

[Matthew Dillon]

:On Mon, 2 Aug 1999, Alfred Perlstein wrote:
:
:>  } \
:>  if (fhlen != 0) { \
:>  nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
:>  bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
:>  if ((nfsd->nd_flag & ND_NFSV3) == 0) \
:>  nfsm_adv(NFSX_V2FH - NFSX_V3FH); \
:>  } \
:>  }
:
:...
:
:> it then rewinds the mbuf pointers (i think) because of the
:>   over "dissection" above.
:> ---
:> 
:> why does it do the copy, then rewind it, it seems like it knows
:> it's doing something wrong and instead of fixing it, it just 
:> compensates after the fact.
:
:yes, replying to my own message.
:
:the only thing i can think of is that the extra data is safely
:ignored because the routines that use these macros seem to
:pass the version of NFS to all the function that they call...
:
:however unless i'm wrong (which i probably am) nfsV2 stuff
:could be made faster if it was correctly noted and less data
:was copied.  It would also DTRT and not access data it isn't
:supposed to :)
:
:it seems like all of the V3 handles are the same length so
:there isn't much to do there...
:
:-Alfred

Well, I must say that it certainly looks like a bug.  It is not going
to blow anything up since the nfsm_dissect() will break out if it runs
out of buffer space, but it certainly seems inefficient.  I am somewhat 
loath to fix anything in NFS that does not create a demonstrateable
problem for fear of creating new problems, though, it is quite possible
that the server code depends on the extra junk in the file handle for
V2 mounts - A full audit of nfs_nqlease.c and nfs_serv.c would be
necessary before this could be fixed.

-Matt
Matthew Dillon 



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

Re: confusion about nfsm_srvmtofh bad behavior?

[Matthew Dillon]

::> it then rewinds the mbuf pointers (i think) because of the
::>   over "dissection" above.
::> ---
::> 
::> why does it do the copy, then rewind it, it seems like it knows
::> it's doing something wrong and instead of fixing it, it just 
::> compensates after the fact.
::
::yes, replying to my own message.
::
::the only thing i can think of is that the extra data is safely
::ignored because the routines that use these macros seem to
::pass the version of NFS to all the function that they call...
::
::however unless i'm wrong (which i probably am) nfsV2 stuff
::could be made faster if it was correctly noted and less data
::was copied.  It would also DTRT and not access data it isn't
::supposed to :)
::
::it seems like all of the V3 handles are the same length so
::there isn't much to do there...
::
::-Alfred
:
:Well, I must say that it certainly looks like a bug.  It is not going
:to blow anything up since the nfsm_dissect() will break out if it runs
:out of buffer space, but it certainly seems inefficient.  I am somewhat 
:loath to fix anything in NFS that does not create a demonstrateable
:problem for fear of creating new problems, though, it is quite possible
:that the server code depends on the extra junk in the file handle for
:V2 mounts - A full audit of nfs_nqlease.c and nfs_serv.c would be
:necessary before this could be fixed.
:
:   -Matt
:   Matthew Dillon 
:   

Oh, p.s.  But in the mean time, if you or someone would like to commit
an XXX comment to document the potential bug / performance problem, I
think that would be very appropriate.  e.g.

/*
 * Extract file handle from NFS stream.   XXX note that the extraction of
 * the file handle for an NFSv2 mount appears to be rather odd.  It is copying
 * NFSX_V3FH bytes instead of NFSX_V2FH and then rewinding the mbuf index.
 */
 
#define nfsm_srvmtofh(f) \
{ int fhlen = NFSX_V3FH; \
if (nfsd->nd_flag & ND_NFSV3) { \
nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
fhlen = fxdr_unsigned(int, *tl); \
...

-Matt
Matthew Dillon 



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

Re: readdirplus is very cool, any other nfs client suggestions?

[Tim Vanderhoek]

On Mon, Aug 02, 1999 at 09:25:52AM +0200, Dag-Erling Smorgrav wrote:
>(there were
> places where make world would bomb because chflags doesn't work on
[...]
>  (check the logs for Makefiles that use
> chflags).
[...]
> r...@des ~# current -l -F Makefile chflags 
> src/Makefile.inc1

Set INSTALLFLAGS_EDIT=:S/schg/,/ to remove these when doing a make
world, if needed.

[A make world actually works from usermode now with the right set of
options (one of which is -DNOGAMES)].


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


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

Re: readdirplus is very cool, any other nfs client suggestions?

[Dag-Erling Smorgrav]

Matthew Dillon  writes:
> The buildworld chflags problems were fixed around a month ago I think.

No, I fixed them in february or march.

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


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

Re: readdirplus is very cool, any other nfs client suggestions?

[Dag-Erling Smorgrav]

Tim Vanderhoek  writes:
> Set INSTALLFLAGS_EDIT=:S/schg/,/ to remove these when doing a make
> world, if needed.

Please try to understand what the issue is before butting in.

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


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

Re: readdirplus is very cool, any other nfs client suggestions?

[Matthew Dillon]

:Matthew Dillon  writes:
:> The buildworld chflags problems were fixed around a month ago I think.
:
:No, I fixed them in february or march.
:
:DES
:-- 
:Dag-Erling Smorgrav - d...@yes.no

Ok, then there is a real good chance localhost mounts will work now.

I'm running a buildworld test right now with /usr/src and /usr/obj both
on NFSv3 localhost mounts.

-Matt
Matthew Dillon 



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

Re: readdirplus is very cool, any other nfs client suggestions?

[Dag-Erling Smorgrav]

Matthew Dillon  writes:
> Ok, then there is a real good chance localhost mounts will work now.

I'm happy to hear that, since NFSv3 is significantly faster than NFSv2
on loopback mounts :)

> I'm running a buildworld test right now with /usr/src and /usr/obj both
> on NFSv3 localhost mounts.

Yeah, I was doing installworlds with /usr, /usr/src and /usr/obj
NFS-mounted (in a chroot tree on the server, because I got tired of
doing it over PLIP).

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


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

FW: Network problems with 3.2R as VMWare Guest OS

[Charles Randall]

Forwarded to -hackers due to a lack of response in -questions.

Charles

-Original Message-
From: Charles Randall [mailto:crand...@matchlogic.com] 
Sent: Friday, July 30, 1999 9:55 AM
To: freebsd-questi...@freebsd.org
Subject: Network problems with 3.2R as VMWare Guest OS


I've been running 3.2R as a VMWare for NT (0.80 beta, build 217) "guest" OS.

All seems well with the exception that the network seems to die occasionally
(no messages in /var/log/messages, I just can't access any other hosts on
the network).

The VMWare virtual network adapter is recognized as,

lnc1:  rev 0x10 int a irq 9 on pci0.16.0
lnc1: PCnet-PCI II address 00:50:56:81:11:24

I can solve this with a simple,

% ifconfig lnc1 down
% ifconfig lnc1 up

Has anyone else experienced this? I suspect a problem in the VMWare virtual
network adapter or the NT driver it installed.

Charles

Charles F. Randall
crand...@matchlogic.com
MatchLogic, Inc.




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


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

Re: Proposing argv for klds and preloaded modules

[Daniel C. Sobral]

Warner Losh wrote:
> 
> In message  
> Juha Nurmela writes:
> : Yes, but (this might be a trademark ;) commonly the arguments would
> : be used during the sysinit->attach, and at that time sysctl has not yet
> : been able to change anything. Use of sysctl would require a sidestep
> : from attach and later continuation with a sysctl_proc. Not a problem,
> : but inconvenient, IMHO. And it's analogous to executing, they too
> : can get arguments.
> 
> I believe that the plan was to make to have more generic stuff so that
> all drivers woudln't have to parse argv...

Modules are not just drivers. Forget about drivers, and try again.
:-)

--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org

- Jordan, God, what's the difference?
- God doesn't belong to the -core.



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

Re: Proposing argv for klds and preloaded modules

[Warner Losh]

In message <37a5c680.3ca1d...@newsguy.com> "Daniel C. Sobral" writes:
: Modules are not just drivers. Forget about drivers, and try again.
: :-)

But the generic mechanism extends beyond just drivers :-)

Warner


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

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message  Dag-Erling Smorgrav writes:
: Allow me to re-quote the message I answered:
: 
: > I vote for allowing inetd.conf to specify a port number instead of a
: > service name...

I've said it before, and I'll say it again: This is an excellent idea!

Warner


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

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message  Dag-Erling Smorgrav writes:
: Daniel Eischen  writes:
: > Dag-Erling Smorgrav wrote:
: > > The correct way to do this is to fix getservbyname() so it accepts
: > > port numbers.
: > Are you sure this is what you want?

I'm 100% positive that I want this.

: >  It may allow an application to
: > use a port number that would otherwise be invalid.

I think he's saying that you could run telnet on port 25, which is
reserved for mail.

I say that I don't care if it allows this.  In fact, I want to be able 
to do things like that...

Warner


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

Re: confusion about nfsm_srvmtofh bad behavior?

[Alfred Perlstein]

On Mon, 2 Aug 1999, Matthew Dillon wrote:

> 
> ::> it then rewinds the mbuf pointers (i think) because of the
> ::>   over "dissection" above.
> ::> ---
> ::> 
> ::> why does it do the copy, then rewind it, it seems like it knows
> ::> it's doing something wrong and instead of fixing it, it just 
> ::> compensates after the fact.
> ::
> ::yes, replying to my own message.
> ::
> ::the only thing i can think of is that the extra data is safely
> ::ignored because the routines that use these macros seem to
> ::pass the version of NFS to all the function that they call...
> ::
> ::however unless i'm wrong (which i probably am) nfsV2 stuff
> ::could be made faster if it was correctly noted and less data
> ::was copied.  It would also DTRT and not access data it isn't
> ::supposed to :)
> ::
> ::it seems like all of the V3 handles are the same length so
> ::there isn't much to do there...
> ::
> ::-Alfred
> :
> :Well, I must say that it certainly looks like a bug.  It is not going
> :to blow anything up since the nfsm_dissect() will break out if it runs
> :out of buffer space, but it certainly seems inefficient.  I am somewhat 
> :loath to fix anything in NFS that does not create a demonstrateable
> :problem for fear of creating new problems, though, it is quite possible
> :that the server code depends on the extra junk in the file handle for
> :V2 mounts - A full audit of nfs_nqlease.c and nfs_serv.c would be
> :necessary before this could be fixed.
> :
> : -Matt
> : Matthew Dillon 
> : 
> 
> Oh, p.s.  But in the mean time, if you or someone would like to commit
> an XXX comment to document the potential bug / performance problem, I
> think that would be very appropriate.  e.g.
> 
> /*
>  * Extract file handle from NFS stream.   XXX note that the extraction of
>  * the file handle for an NFSv2 mount appears to be rather odd.  It is copying
>  * NFSX_V3FH bytes instead of NFSX_V2FH and then rewinding the mbuf index.
>  */
>  
> #define nfsm_srvmtofh(f) \
> { int fhlen = NFSX_V3FH; \
> if (nfsd->nd_flag & ND_NFSV3) { \
> nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
> fhlen = fxdr_unsigned(int, *tl); \
>   ...

The whole file needs some  documentation. :)
I stared at that for so long wondering why the heck it was doing that.

Is there a chance you could give this some of your famous regression
testing?

http://big.endian.org/~bright/freebsd/patches/nfsm_subs.diff

This is a patch that Peter Wemm proposed however he had this:

!   if (fhlen < NFSX_V3FH) { \
!   bzero((caddr_t)(f) + fhlen, NFSX_V3FH - fhlen); \
!   } \

right before the while(0) instead of the else clause with the 
full bzero.

i'd rather get rid of the extra copying going on and since
previously it was filled with garbage from the rest of the RPC
structure i don't think it's nessesary.

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





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

Re: Mentioning RFC numbers in /etc/services

[Bill Fumerola]

On Mon, 2 Aug 1999, Warner Losh wrote:

> I say that I don't care if it allows this.  In fact, I want to be able 
> to do things like that...

Copying the telnet line and changing the first word to 'http' does wonders
for being to access machines from inside a school district's firewall.

Choosing ports by number would be nice, however the same objections Matt
had with changing our API ring some buzzers in my head too, however the
evil side of me says "screw whoever is porting inetd, we like functionality.

The evil side normally wins.

-- 
- bill fumerola - bi...@chc-chimes.com - BF1560 - computer horizons corp -
- ph:(800) 252-2421 - bfume...@computerhorizons.com - bi...@freebsd.org  -



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

Re: confusion about nfsm_srvmtofh bad behavior?

[Matthew Dillon]

:The whole file needs some  documentation. :)
:I stared at that for so long wondering why the heck it was doing that.

NFS is the worst-documented code in the kernel, VFS is second-worst.

Without commit privs, documenting existing code eats too much of my time
I'm afraid.  With commit privs I tended to document as I went.

:Is there a chance you could give this some of your famous regression
:testing?
:...
:http://big.endian.org/~bright/freebsd/patches/nfsm_subs.diff

Lemme look at the patch hmm.  The patch looks reasonable, I will
test it as soon as I finish running the buildworld test on localhost
NFS mounts.

My source tree is getting a little messy.  We have madvise() broken open
too.  Hopefully we will be able to get that committed soon.

-Matt
Matthew Dillon 


:i'd rather get rid of the extra copying going on and since
:previously it was filled with garbage from the rest of the RPC
:structure i don't think it's nessesary.
:
:-Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] 
:systems administrator and programmer



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

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message  Bill 
Fumerola writes:
: Copying the telnet line and changing the first word to 'http' does wonders
: for being to access machines from inside a school district's firewall.

What if the service has no name?

: Choosing ports by number would be nice, however the same objections Matt
: had with changing our API ring some buzzers in my head too, however the
: evil side of me says "screw whoever is porting inetd, we like functionality.
: 
: The evil side normally wins.

I don't think we should change getportbyname.  If the getportbyname
fails, see if a strtol returns a number, and if so use that.  I don't
see what is so hard about doing that.

If someone wants to run a service on a port that it wasn't desinged
for, they can still do it today.  I don't see what the argument
against this change could possibly be.  There is no evil here.

Warner


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

Re: Mentioning RFC numbers in /etc/services

[Bill Fumerola]

On Mon, 2 Aug 1999, Warner Losh wrote:

> I don't think we should change getportbyname.  If the getportbyname
> fails, see if a strtol returns a number, and if so use that.  I don't
> see what is so hard about doing that.

I agree. The change should be made in inetd, not in getportbyname()

> If someone wants to run a service on a port that it wasn't desinged
> for, they can still do it today.  I don't see what the argument
> against this change could possibly be.  There is no evil here.

Changing getportbyname() would be, which is what was discussed before.

-- 
- bill fumerola - bi...@chc-chimes.com - BF1560 - computer horizons corp -
- ph:(800) 252-2421 - bfume...@computerhorizons.com - bi...@freebsd.org  -



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

Re: confusion about nfsm_srvmtofh bad behavior?

[Peter Wemm]

Alfred Perlstein wrote:
> On Mon, 2 Aug 1999, Matthew Dillon wrote:
> 
> > 
> > ::> it then rewinds the mbuf pointers (i think) because of the
> > ::>   over "dissection" above.
> > ::> ---
> > ::> 
> > ::> why does it do the copy, then rewind it, it seems like it knows
> > ::> it's doing something wrong and instead of fixing it, it just 
> > ::> compensates after the fact.
> > ::
> > ::yes, replying to my own message.
> > ::
> > ::the only thing i can think of is that the extra data is safely
> > ::ignored because the routines that use these macros seem to
> > ::pass the version of NFS to all the function that they call...
> > ::
> > ::however unless i'm wrong (which i probably am) nfsV2 stuff
> > ::could be made faster if it was correctly noted and less data
> > ::was copied.  It would also DTRT and not access data it isn't
> > ::supposed to :)
> > ::
> > ::it seems like all of the V3 handles are the same length so
> > ::there isn't much to do there...
> > ::
> > ::-Alfred
> > :
> > :Well, I must say that it certainly looks like a bug.  It is not going
> > :to blow anything up since the nfsm_dissect() will break out if it runs
> > :out of buffer space, but it certainly seems inefficient.  I am somewha
t 
> > :loath to fix anything in NFS that does not create a demonstrateable
> > :problem for fear of creating new problems, though, it is quite possibl
e
> > :that the server code depends on the extra junk in the file handle for
> > :V2 mounts - A full audit of nfs_nqlease.c and nfs_serv.c would be
> > :necessary before this could be fixed.
> > :
> > :   -Matt
> > :   Matthew Dillon 
> > :   
> > 
> > Oh, p.s.  But in the mean time, if you or someone would like to commit
> > an XXX comment to document the potential bug / performance problem, I
> > think that would be very appropriate.  e.g.
> > 
> > /*
> >  * Extract file handle from NFS stream.   XXX note that the extraction of
> >  * the file handle for an NFSv2 mount appears to be rather odd.  It is copy
ing
> >  * NFSX_V3FH bytes instead of NFSX_V2FH and then rewinding the mbuf index.
> >  */
> >  
> > #define nfsm_srvmtofh(f) \
> > { int fhlen = NFSX_V3FH; \
> > if (nfsd->nd_flag & ND_NFSV3) { \
> > nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
> > fhlen = fxdr_unsigned(int, *tl); \
> > ...
> 
> The whole file needs some  documentation. :)
> I stared at that for so long wondering why the heck it was doing that.
> 
> Is there a chance you could give this some of your famous regression
> testing?
> 
> http://big.endian.org/~bright/freebsd/patches/nfsm_subs.diff
> 
> This is a patch that Peter Wemm proposed however he had this:
> 
> !   if (fhlen < NFSX_V3FH) { \
> !   bzero((caddr_t)(f) + fhlen, NFSX_V3FH - fhlen); \
> !   } \
> 
> right before the while(0) instead of the else clause with the 
> full bzero.
> 
> i'd rather get rid of the extra copying going on and since
> previously it was filled with garbage from the rest of the RPC
> structure i don't think it's nessesary.

Right now it seems we're generating 8 bytes of fsid and 12 (padded to 16)
bytes of handle data in the common case for a total of 24 bytes of filehandle.
Then we pad that to 32 bytes for V2 or 64 bytes for V3, with random crud.
Then we copy this around, store it all in memory, transmit it over the wire,
etc.  It's a nightmare.

NFSv2 filehandles are fixed at 32 bytes long.  For V3 we could probably just
transmit 24 byte filehandles rather than 64.  (I'll reread the spec to make
sure there isn't a v3 minimum size).

That explicit zero on the end is probably redundant since we've been using
random data in it's place since day 1.  (We do need (I think) the fhlen ==
0 bzero though).

Cheers,
-Peter




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

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message  Bill 
Fumerola writes:
: I agree. The change should be made in inetd, not in getportbyname()

Or getservbyname (which is really what you'd want to change).  I have
patches to inetd that I've enclosed here.  They are gorss, but the
code itself doesn't lend itself to non-gross patches w/o some rework,
which I was too lazy to do this morning.

Warner

Index: inetd.c
===
RCS file: /home/imp/FreeBSD/CVS/src/usr.sbin/inetd/inetd.c,v
retrieving revision 1.70
diff -u -r1.70 inetd.c
--- inetd.c 1999/07/26 06:39:46 1.70
+++ inetd.c 1999/08/02 17:27:52
@@ -744,6 +744,7 @@
 {
struct servtab *sep, *new, **sepp;
long omask;
+   int p;
 
if (!setconfig()) {
syslog(LOG_ERR, "%s: %m", CONFIG);
@@ -832,15 +833,21 @@
if (!sep->se_rpc) {
sp = getservbyname(sep->se_service, sep->se_proto);
if (sp == 0) {
+   if ((p = strtol(sep->se_service, 
+   (char **NULL), 10))) {
+   sep->se_ctrladdr.sin_port = htons(p);
+   goto numeric_override;
+   }
syslog(LOG_ERR, "%s/%s: unknown service",
sep->se_service, sep->se_proto);
sep->se_checked = 0;
continue;
}
if (sp->s_port != sep->se_ctrladdr.sin_port) {
+   sep->se_ctrladdr.sin_port = sp->s_port;
+numeric_override:
sep->se_ctrladdr.sin_family = AF_INET;
sep->se_ctrladdr.sin_addr = bind_address;
-   sep->se_ctrladdr.sin_port = sp->s_port;
if (sep->se_fd >= 0)
close_sep(sep);
}


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

Re: readdirplus is very cool, any other nfs client suggestions?

[Matthew Dillon]

:Matthew Dillon  writes:
:> Ok, then there is a real good chance localhost mounts will work now.
:
:I'm happy to hear that, since NFSv3 is significantly faster than NFSv2
:on loopback mounts :)
:
:> I'm running a buildworld test right now with /usr/src and /usr/obj both
:> on NFSv3 localhost mounts.
:
:Yeah, I was doing installworlds with /usr, /usr/src and /usr/obj
:NFS-mounted (in a chroot tree on the server, because I got tired of
:doing it over PLIP).
:
:DES
:-- 
:Dag-Erling Smorgrav - d...@yes.no

My buildworld finished... it worked!

Now on to the NFSv2 fhlen patch testing.  I haven't run v2 in several
months, hopefully it still works :-)

Filesystem1K-blocks UsedAvail Capacity  Mounted on
/dev/da0s1a   6350349194 922984%/
/dev/da0e 63503 65945182911%/var
/dev/da0f 63503758416 0%/var/tmp
/dev/da0g762223   409496   29175058%/usr
/dev/da1e   1937983   533730  124921530%/usr/ports
procfs440   100%/proc
209.157.86.2:/FreeBSD   5541549  1666874  343135233%/FreeBSD
mfs:250   48415144541 0%/usr/src/sys/compile
/dev/da0h   2338236  1026582  112459648%/mnt
localhost:/mnt  2338236  1026582  112459648%/usr/obj
localhost:/mnt/fbsd42338236  1026582  112459648%/usr/src

-Matt
Matthew Dillon 


Client Info:
Rpc Counts:
  Getattr   SetattrLookup  Readlink  Read WriteCreateRemove
0 11072   1225413   875112634291389 28334  4476
   Rename  Link   Symlink Mkdir Rmdir   Readdir  RdirPlusAccess
1017151  1315  1976   181  9607 0684339
MknodFsstatFsinfo  PathConfCommitGLeaseVacate Evict
0 40637 4 0 34030 0 0 0
Rpc Info:
 TimedOut   Invalid X Replies   Retries  Requests
0 0  2762  9845   2456504
Cache Info:
Attr HitsMisses Lkup HitsMisses BioR HitsMisses BioW HitsMisses
 13741790633709  10186640   1223043   2103674112555526820291389
BioRLHitsMisses BioD HitsMisses DirE HitsMisses
23340   875 64231  9607 24430 0

Server Info:
  Getattr   SetattrLookup  Readlink  Read WriteCreateRemove
0 11072   1184725   873 65872292432 28334  4476
   Rename  Link   Symlink Mkdir Rmdir   Readdir  RdirPlusAccess
1017151  1315  1976   181  5437 0618927
MknodFsstatFsinfo  PathConfCommitGLeaseVacate Evict
0 36461 3 0 34093 0 0 0
Server Ret-Failed
  1080044
Server Faults
0
Server Cache Stats:
   Inprog  Idem  Non-idemMisses
 6973   697   784   2295706
Server Lease Stats:
   Leases PeakL   GLeases
0 0 0
Server Write Gathering:
 WriteOps  WriteRPC   Opsaved
   292432292432 0



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

Re: Proposing argv for klds and preloaded modules

[Daniel C. Sobral]

Warner Losh wrote:
> 
> In message <37a5c680.3ca1d...@newsguy.com> "Daniel C. Sobral" writes:
> : Modules are not just drivers. Forget about drivers, and try again.
> : :-)
> 
> But the generic mechanism extends beyond just drivers :-)

Ah, I recall now. Something similar to the way X works, with all the
information stored in a file instead of passed on the command line.

If things are passed on the command line, we put a getopt() in the
kernel and that's that. Get the _string_ to the application, and let
it do it's job. We'll seriously regret anything else.

For that matter, when I was working on loader's commands, I want to
pre-process their arguments. That idea was shot down on the grounds
that we can't foresee what the applications will need as parameters.
The same applies here, right?

So, here is my take. On one hand, we have Juha's code. The change
proposed needs a new syscall. The sooner we make the change,
assuming we are making it at all, the less pain. It provides a way
of getting parameters that is compatible with what is already
possible with loader (ie, the module need not differentiate between
it's method of loading). The code is working and ready.

On the other hand, we have a vaguely defined vapourware that looks
real cool, and will be done some day after other outstanding
priorities are dealt with.

I'm not a fan of adding code to FreeBSD just because it exists. That
_is_ one thing we do different from another popular open source OS,
and which serves us well. If the code is crass, does not serve us
well, is kitchen-sink bloating, or goes in a direction we see as a
dead-end, it should not be imported.

Alas, it seems none of the above applies. Even if we *do* come up
with something better later, this code won't get in the way any more
than what's in loader(8) already does. In that light, I think we
ought to import it into our tree.

BTW, won't any of the kld gods speak up?

--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org

- Jordan, God, what's the difference?
- God doesn't belong to the -core.



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

Re: confusion about nfsm_srvmtofh bad behavior?

[Alfred Perlstein]

On Tue, 3 Aug 1999, Peter Wemm wrote:

> Alfred Perlstein wrote:
> > On Mon, 2 Aug 1999, Matthew Dillon wrote:
> > 
> > http://big.endian.org/~bright/freebsd/patches/nfsm_subs.diff
> > 
> > This is a patch that Peter Wemm proposed however he had this:
> > 
> > !   if (fhlen < NFSX_V3FH) { \
> > !   bzero((caddr_t)(f) + fhlen, NFSX_V3FH - fhlen); \
> > !   } \
> > 
> > right before the while(0) instead of the else clause with the 
> > full bzero.
> > 
> > i'd rather get rid of the extra copying going on and since
> > previously it was filled with garbage from the rest of the RPC
> > structure i don't think it's nessesary.
> 
> Right now it seems we're generating 8 bytes of fsid and 12 (padded to 16)
> bytes of handle data in the common case for a total of 24 bytes of filehandle.
> Then we pad that to 32 bytes for V2 or 64 bytes for V3, with random crud.
> Then we copy this around, store it all in memory, transmit it over the wire,
> etc.  It's a nightmare.

yes, ick! :)

> NFSv2 filehandles are fixed at 32 bytes long.  For V3 we could probably just
> transmit 24 byte filehandles rather than 64.  (I'll reread the spec to make
> sure there isn't a v3 minimum size).

there isn't, the only reason i can think of forcing it to the full
64 bytes is that it may interact badly with other NFS implementations
that may not handle it correctly.

> 
> That explicit zero on the end is probably redundant since we've been using
> random data in it's place since day 1.  (We do need (I think) the fhlen ==
> 0 bzero though).

It should probably error and do the same thing that happens above,
however, i'm too tired to determine if it's safe to do that after
the second nfsm_dissect(), and since it's an error condition that
would only happen with a corrupted packet or somesuch it can 
probably be left alone.

I appreciate the time you've taken on IRC to enlighten me about
these things.

thank you,
-Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] 
systems administrator and programmer
Wintelcom - http://www.wintelcom.net/



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

Re: confusion about nfsm_srvmtofh bad behavior?

[Matthew Dillon]

:Right now it seems we're generating 8 bytes of fsid and 12 (padded to 16)
:bytes of handle data in the common case for a total of 24 bytes of filehandle.
:Then we pad that to 32 bytes for V2 or 64 bytes for V3, with random crud.
:Then we copy this around, store it all in memory, transmit it over the wire,
:etc.  It's a nightmare.
:
:NFSv2 filehandles are fixed at 32 bytes long.  For V3 we could probably just
:transmit 24 byte filehandles rather than 64.  (I'll reread the spec to make
:sure there isn't a v3 minimum size).
:
:That explicit zero on the end is probably redundant since we've been using
:random data in it's place since day 1.  (We do need (I think) the fhlen ==
:0 bzero though).
:
:Cheers,
:-Peter

Well, judging from the code I think that NFSv3 handles are locked in
at 64 bytes.Otherwise the nfsm_srvmtofh() macro will dump out
when fhlen != NFSX_V3FH.  The macro could be wrong, but I would have
thought that we'd get more intereoperability complaints then.

We definitely have to zero the handle if fhlen == 0 -- I haven't audited
the code but my guess is that users of the macro may assume that the fh
has been zerod in certain degenerate cases.  I'll bet the handle is
optional in parts of the protocol.

#define nfsm_srvmtofh(f) \
do { \
int fhlen; \
if (nfsd->nd_flag & ND_NFSV3) { \
nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
fhlen = fxdr_unsigned(int, *tl); \
if (fhlen != 0 && fhlen != NFSX_V3FH) { \
error = EBADRPC; \
nfsm_reply(0); \
} \
...

-Matt
Matthew Dillon 



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

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message <199908021754.daa25...@avalon.reed.wattle.id.au> Darren Reed writes:
: Why not just use the changes NetBSD made to their inetd ~6 years ago ?

Didn't know about them?

Warner


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

Re: readdirplus is very cool, any other nfs client suggestions?

[Doug]

On 2 Aug 1999, Dag-Erling Smorgrav wrote:

> Alfred Perlstein  writes:
> > DES: can you elaborate?  you think it may cause problems with amd
> > since it's like an NFS buffer isn't it and would work over the 
> > loopback...
> 
> I used loopback mounts to test NFS make worlds a while ago

Hrrmmm... I'm not sure where the concern about loopback stuff
comes from. Does amd use the loopback interface to communicate with
anything? 

Thanks,

Doug
-- 
On account of being a democracy and run by the people, we are the only
nation in the world that has to keep a government four years, no matter
what it does.
-- Will Rogers



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

Re: Proposing argv for klds and preloaded modules

[Doug Rabson]

On Tue, 3 Aug 1999, Daniel C. Sobral wrote:

> Warner Losh wrote:
> > 
> > In message <37a5c680.3ca1d...@newsguy.com> "Daniel C. Sobral" writes:
> > : Modules are not just drivers. Forget about drivers, and try again.
> > : :-)
> > 
> > But the generic mechanism extends beyond just drivers :-)
> 
> Ah, I recall now. Something similar to the way X works, with all the
> information stored in a file instead of passed on the command line.
> 
> If things are passed on the command line, we put a getopt() in the
> kernel and that's that. Get the _string_ to the application, and let
> it do it's job. We'll seriously regret anything else.
> 
> For that matter, when I was working on loader's commands, I want to
> pre-process their arguments. That idea was shot down on the grounds
> that we can't foresee what the applications will need as parameters.
> The same applies here, right?
> 
> So, here is my take. On one hand, we have Juha's code. The change
> proposed needs a new syscall. The sooner we make the change,
> assuming we are making it at all, the less pain. It provides a way
> of getting parameters that is compatible with what is already
> possible with loader (ie, the module need not differentiate between
> it's method of loading). The code is working and ready.
> 
> On the other hand, we have a vaguely defined vapourware that looks
> real cool, and will be done some day after other outstanding
> priorities are dealt with.
> 
> I'm not a fan of adding code to FreeBSD just because it exists. That
> _is_ one thing we do different from another popular open source OS,
> and which serves us well. If the code is crass, does not serve us
> well, is kitchen-sink bloating, or goes in a direction we see as a
> dead-end, it should not be imported.
> 
> Alas, it seems none of the above applies. Even if we *do* come up
> with something better later, this code won't get in the way any more
> than what's in loader(8) already does. In that light, I think we
> ought to import it into our tree.
> 
> BTW, won't any of the kld gods speak up?

I'm currently extremely distracted by non-FreeBSD work and will be so
until after SIGGRAPH. If Peter doesn't show an interest before then remind
me in a couple of weeks.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: confusion about nfsm_srvmtofh bad behavior?

[Mike Smith]

> 
> ok:
> 
> #define nfsm_srvmtofh(f) \
>   { int fhlen = NFSX_V3FH; \
>   if (nfsd->nd_flag & ND_NFSV3) { \
>   nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
>   fhlen = fxdr_unsigned(int, *tl); \
>   if (fhlen == 0) { \
>   bzero((caddr_t)(f), NFSX_V3FH); \
>   } else if (fhlen != NFSX_V3FH) { \
>   error = EBADRPC; \
>   nfsm_reply(0); \
>   } \
>   } \
>   if (fhlen != 0) { \
>   nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
>   bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
>   if ((nfsd->nd_flag & ND_NFSV3) == 0) \
>   nfsm_adv(NFSX_V2FH - NFSX_V3FH); \
>   } \
>   }
> 
> notice the bcopy?  i don't really understand why we always
> seem to copy 64 bytes (NFSX_V3FH), isn't this a bug?

Yeah, you could probably rewrite as:

#define nfsm_srvmtofh(f) \
{ int fhlen; \
if (nfsd->nd_flag & ND_NFSV3) { \
nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
fhlen = fxdr_unsigned(int, *tl); \
if (fhlen == 0) { \
bzero((caddr_t)(f), NFSX_V3FH); \
} else if (fhlen != NFSX_V3FH) { \
error = EBADRPC; \
nfsm_reply(0); \
} else { \
nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
}\
} else {
nfsm_dissect(tl, u_int32_t *, NFSX_V2FH); \
bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V2FH); \
} \
}

which avoids using fhlen as an argument to anything (speed) and limits 
the bcopy size appropriately by protocol.

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




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

Initio INI-* SCSI card support

[David O'Brien]

Has anybody taken a look at the FreeBSD driver source at
http://www.initio.com/source.zip for the INI-* cards?  Is this something
we should import into -CURRENT?

-- 
-- David(obr...@nuxi.com  -or-  obr...@freebsd.org)


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

Re: Initio INI-* SCSI card support

[Guy Helmer]

On Mon, 2 Aug 1999, David O'Brien wrote:

> Has anybody taken a look at the FreeBSD driver source at
> http://www.initio.com/source.zip for the INI-* cards?  Is this something
> we should import into -CURRENT?

It would be handy for me if it were brought in.  FWIW, I'm using this
driver with an SIIG AP-10 SCSI card under -current.

Guy

Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science 
Research Assistant, Ames Laboratory   --- ghel...@scl.ameslab.gov
Research Assistant, Dept. of Computer Science   ---   ghel...@cs.iastate.edu
http://www.cs.iastate.edu/~ghelmer



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

Re: Mentioning RFC numbers in /etc/services

[Assar Westerlund]

Warner Losh  writes:
> Or getservbyname (which is really what you'd want to change).  I have
> patches to inetd that I've enclosed here.  They are gorss, but the
> code itself doesn't lend itself to non-gross patches w/o some rework,
> which I was too lazy to do this morning.

Or you might as well fix it for RPCs at the same time.

/assar

--- inetd.c.origMon Aug  2 22:35:28 1999
+++ inetd.c Mon Aug  2 22:41:52 1999
@@ -830,34 +830,50 @@
continue;
}
if (!sep->se_rpc) {
+   int port;
+
sp = getservbyname(sep->se_service, sep->se_proto);
if (sp == 0) {
-   syslog(LOG_ERR, "%s/%s: unknown service",
+   port = htons(strtol (sep->se_service,
+NULL, 0));
+   if (port == 0) {
+   syslog(LOG_ERR,
+  "%s/%s: unknown service",
sep->se_service, sep->se_proto);
sep->se_checked = 0;
continue;
}
-   if (sp->s_port != sep->se_ctrladdr.sin_port) {
+   } else
+   port = sp->s_port;
+   if (port != sep->se_ctrladdr.sin_port) {
sep->se_ctrladdr.sin_family = AF_INET;
sep->se_ctrladdr.sin_addr = bind_address;
-   sep->se_ctrladdr.sin_port = sp->s_port;
+   sep->se_ctrladdr.sin_port = port;
if (sep->se_fd >= 0)
close_sep(sep);
}
} else {
+   int rpc_number;
+
rpc = getrpcbyname(sep->se_service);
if (rpc == 0) {
-   syslog(LOG_ERR, "%s/%s unknown RPC service.",
+   rpc_number = strtol (sep->se_service,
+NULL, 0);
+   if (rpc_number == 0) {
+   syslog(LOG_ERR,
+  "%s/%s unknown RPC service.",
sep->se_service, sep->se_proto);
if (sep->se_fd != -1)
(void) close(sep->se_fd);
sep->se_fd = -1;
continue;
}
-   if (rpc->r_number != sep->se_rpc_prog) {
+   } else
+   rpc_number = sep->se_rpc_prog;
+   if (rpc_number != sep->se_rpc_prog) {
if (sep->se_rpc_prog)
unregisterrpc(sep);
-   sep->se_rpc_prog = rpc->r_number;
+   sep->se_rpc_prog = rpc_number;
if (sep->se_fd != -1)
(void) close(sep->se_fd);
sep->se_fd = -1;


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

Re: So, back on the topic of enabling bpf in GENERIC...

[Peter Jeremy]

In message <37a3b701.851df...@softweyr.com> Wes Peters writes:
>Do we have a list of all services that use bpf?

In the base system, ipfilter et al (ie ipsend(1)), tcpdump,
rbootd, rarpd and dhcp.  Someone who's got a complete set of ports
might like to comment on what ports need bpf.

Of these, we need to leave rarpd, dhcp and maybe rbootd running,
whilst inhibiting tcpdump and ipfilter (or at least stop them
being used to sniff networks)[*].

As I've already mentioned elsewhere, a fairly easy option would be
to create a `crippled' BPF - which included a hard-wired filter
that only returned broadcast packets and disabled BIOCSETF and
maybe BIOCPROMISC.  The crippled BPF would be part of GENERIC, and
anyone who wanted the full functionality could re-compile without
the `CRIPPLED_BPF' flag.  Another option would be to have the BPF
crippling based on the secure-level (or driven via a specific
`raise-only' sysctl).

Apart from the hard-wired filters, the code to do this is trivial
(though not as trivial as simply blocking bpf_open is securelevel
> 1).

[*] I personally don't believe that the mere presence of bpf is a
security hole.  By default you need root to activate it (and if
someone undesirable has root access, you have other problems).
It's also trivially easy to sniff a network from a Windoze PC.

Peter


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

Jail syscalls

[Sebastien GIORIA]

Hi guys,
 
I'm in the process of evaluating (next month) some box who
made the same that jail syscall but this is linux boxes :-( or Solaris 
boxes. So, If I can make a FreeBSD-STABLE (3.X box) working with 
jail in the competition, I've got a good point for my boss. 
 
We are currently working with some FreeBSD boxes as mail, dns, 
radius servers and if we can made webserver, this will be a great
work for us because we love it.
 
So my question is; Are they some guys who have patchs for 
a -STABLE box ? This is not a problem if this is not actually
supported because the linux boxes are only ALPHA boxes.
 
My process decision is in the next 6 months, so if some 
guys from core (particuliary PHK; if I remenber this is 
the responsible of the jail subsystem).
 
 Thank for your responses
 
S.

-- 
FranceNet Security Administrator sebastien.gio...@francenet.fr 
French FreeBSD Documentation Projectgio...@freebsd.org
Tout FreeBSD en Francais http://www.FreeBSD-fr.org


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

Re: Mentioning RFC numbers in /etc/services

[Brian Somers]

dil...@apollo.backplane.com said:
> :The correct way to do this is to fix getservbyname() so it accepts
> :port numbers. : :DES :--  :Dag-Erling Smorgrav - d...@flood.ping.uio.no
> 
> 
> If we were to depend on this, it would break code compatibility with 
> other UNIXes for no good reason.   For example, someone porting inetd
> from FreeBSD to something else would not get a compatible result without
> undoing the 'fix'.
> 
> 'Fixing' getservbyname() is a really bad idea. 

I agree - unless all the BSDs agree, changing this sort of thing is 
just going to disfavour FreeBSD as a development platform.

I've been stung with things like pipe() for exactly the same reasons. 
IMHO, pipe() should *not* behave like socketpair() as it encourages 
FreeBSD developers to write bad code :-(

-- 
Brian 
     
Don't _EVER_ lose your sense of humour !  




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

Re: Initio INI-* SCSI card support

[Kenneth D. Merry]

Guy Helmer wrote...
> On Mon, 2 Aug 1999, David O'Brien wrote:
> 
> > Has anybody taken a look at the FreeBSD driver source at
> > http://www.initio.com/source.zip for the INI-* cards?  Is this something
> > we should import into -CURRENT?
> 
> It would be handy for me if it were brought in.  FWIW, I'm using this
> driver with an SIIG AP-10 SCSI card under -current.

I've seen it, as has Justin.  There are actually two drivers.

Justin still needs to review it, and there were some copyright problems
with one of the drivers last time I checked.  (one file without a copyright,
one file with a restrictive copyright, and one file with a BSD copyright)

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


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

Re: readdirplus is very cool, any other nfs client suggestions?

[Matthew Dillon]

:Now on to the NFSv2 fhlen patch testing.  I haven't run v2 in several
:months, hopefully it still works :-)

My buildworld using the NFSv2 file handle length patch succeeded as
well.

I've included the patch again for reference.  (Note:  I didn't write
this patch, refer back to the thread for that info).

-Matt

Index: nfsm_subs.h
===
RCS file: /home/ncvs/src/sys/nfs/nfsm_subs.h,v
retrieving revision 1.24
diff -u -r1.24 nfsm_subs.h
--- nfsm_subs.h 1999/06/23 04:44:14 1.24
+++ nfsm_subs.h 1999/08/02 17:22:38
@@ -419,24 +419,25 @@
} }
 
 #define nfsm_srvmtofh(f) \
-   { int fhlen = NFSX_V3FH; \
+   do { \
+   int fhlen; \
if (nfsd->nd_flag & ND_NFSV3) { \
nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
fhlen = fxdr_unsigned(int, *tl); \
-   if (fhlen == 0) { \
-   bzero((caddr_t)(f), NFSX_V3FH); \
-   } else if (fhlen != NFSX_V3FH) { \
+   if (fhlen != 0 && fhlen != NFSX_V3FH) { \
error = EBADRPC; \
nfsm_reply(0); \
} \
+   } else { \
+   fhlen = NFSX_V2FH; \
} \
if (fhlen != 0) { \
-   nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
-   bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
-   if ((nfsd->nd_flag & ND_NFSV3) == 0) \
-   nfsm_adv(NFSX_V2FH - NFSX_V3FH); \
+   nfsm_dissect(tl, u_int32_t *, fhlen); \
+   bcopy((caddr_t)tl, (caddr_t)(f), fhlen); \
+   } else { \
+   bzero((caddr_t)(f), NFSX_V3FH); /* XXX why not do a 
EBADRPC? */ \
} \
-   }
+   } while (0)
 
 #definenfsm_clget \
if (bp >= be) { \


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

Re: Mentioning RFC numbers in /etc/services

[Brian Somers]

[.]
> @@ -832,15 +833,21 @@
>   if (!sep->se_rpc) {
>   sp = getservbyname(sep->se_service, sep->se_proto);
>   if (sp == 0) {
> + if ((p = strtol(sep->se_service, 
> + (char **NULL), 10))) {
> + sep->se_ctrladdr.sin_port = htons(p);
> + goto numeric_override;
> + }
>   syslog(LOG_ERR, "%s/%s: unknown service",
>   sep->se_service, sep->se_proto);
>   sep->se_checked = 0;
>   continue;
>   }
>   if (sp->s_port != sep->se_ctrladdr.sin_port) {
> + sep->se_ctrladdr.sin_port = sp->s_port;
> +numeric_override:
>   sep->se_ctrladdr.sin_family = AF_INET;
>   sep->se_ctrladdr.sin_addr = bind_address;
> - sep->se_ctrladdr.sin_port = sp->s_port;
>   if (sep->se_fd >= 0)
>   close_sep(sep);
>   }
[.]

Yes, but do it the other way 'round - strtol first, if it's not all 
numeric, getservbyname().
-- 
Brian 
     
Don't _EVER_ lose your sense of humour !  




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

Re: readdirplus is very cool, any other nfs client suggestions?

[Alfred Perlstein]

On Mon, 2 Aug 1999, Matthew Dillon wrote:

> :Now on to the NFSv2 fhlen patch testing.  I haven't run v2 in several
> :months, hopefully it still works :-)
> 
> My buildworld using the NFSv2 file handle length patch succeeded as
> well.
> 
> I've included the patch again for reference.  (Note:  I didn't write
> this patch, refer back to the thread for that info).
> 
>   -Matt

any percievable performance gain? I doubt it...

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



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

Re: Mentioning RFC numbers in /etc/services

[David Scheidt]

On Mon, 2 Aug 1999, Brian Somers wrote:


> Yes, but do it the other way 'round - strtol first, if it's not all 
> numeric, getservbyname().

Can't you have all numeric service names?  
>

David scheidt 




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

Re: FW: Network problems with 3.2R as VMWare Guest OS

[Mike Smith]

> Forwarded to -hackers due to a lack of response in -questions.

The lnc driver is not the most wonderful; you might want to talk to 
Paul Richards (p...@freebsd.org) about this.

> Charles
> 
> -Original Message-
> From: Charles Randall [mailto:crand...@matchlogic.com] 
> Sent: Friday, July 30, 1999 9:55 AM
> To: freebsd-questi...@freebsd.org
> Subject: Network problems with 3.2R as VMWare Guest OS
> 
> 
> I've been running 3.2R as a VMWare for NT (0.80 beta, build 217) "guest" OS.
> 
> All seems well with the exception that the network seems to die occasionally
> (no messages in /var/log/messages, I just can't access any other hosts on
> the network).
> 
> The VMWare virtual network adapter is recognized as,
> 
>   lnc1:  rev 0x10 int a irq 9 on pci0.16.0
>   lnc1: PCnet-PCI II address 00:50:56:81:11:24
> 
> I can solve this with a simple,
> 
>   % ifconfig lnc1 down
>   % ifconfig lnc1 up
> 
> Has anyone else experienced this? I suspect a problem in the VMWare virtual
> network adapter or the NT driver it installed.
> 
> Charles
> 
> Charles F. Randall
> crand...@matchlogic.com
> MatchLogic, Inc.
> 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-questions" in the body of the message
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 

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




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

Re: readdirplus is very cool, any other nfs client suggestions?

[Matthew Dillon]

:> My buildworld using the NFSv2 file handle length patch succeeded as
:> well.
:> 
:> I've included the patch again for reference.  (Note:  I didn't write
:> this patch, refer back to the thread for that info).
:> 
:>  -Matt
:
:any percievable performance gain? I doubt it...
:
:-Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] 

I didn't measure the performance.  I doubt it.

-Matt
Matthew Dillon 



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

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message <199908022217.xaa02...@keep.lan.awfulhak.org> Brian Somers writes:
: Yes, but do it the other way 'round - strtol first, if it's not all 
: numeric, getservbyname().

I did it getservbyname first in case there were any legacy services
that were all numbers.  Traditionally, this is hwo things were done
with IP addresses, although a quickie survey shows it to be a mixed
bag.  The biggest reason for not doing getservbyname first is that it
will hang (long timeout) if the databsae behind it goes away.

Warner


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

Re: Jail syscalls

[Ollivier Robert]

According to Sebastien GIORIA:
> My process decision is in the next 6 months, so if some 
> guys from core (particuliary PHK; if I remenber this is 
> the responsible of the jail subsystem).

It will probably not be very easy putting this into 3.x, considering the
number of files concerned although the number of lines changed is not that
big.

phk 1999/04/28 04:38:54 PDT

  Modified files:
usr.sbin Makefile 
sys/conf files 
sys/gnu/ext2fs   ext2_vnops.c 
sys/kern init_main.c init_sysent.c kern_exit.c 
 kern_fork.c kern_ktrace.c kern_mib.c 
 kern_proc.c kern_prot.c kern_resource.c 
 kern_sig.c kern_sysctl.c kern_xxx.c 
 sys_process.c syscalls.c uipc_usrreq.c 
 vfs_syscalls.c vfs_vnops.c 
sys/miscfs/devfs devfs_vnops.c 
sys/miscfs/procfsprocfs.h procfs_status.c procfs_vnops.c 
sys/msdosfs  msdosfs_vnops.c 
sys/net  bpf.c if.c if.h rtsock.c 
sys/netinet  in.h in_pcb.c in_pcb.h tcp_subr.c 
 tcp_usrreq.c udp_usrreq.c 
sys/nfs  nfs_serv.c 
sys/sys  proc.h syscall-hide.h syscall.h 
 syscall.mk sysctl.h sysproto.h ucred.h 
 unpcb.h 
sys/ufs/ufs  ufs_vfsops.c ufs_vnops.c 
bin/ps   print.c ps.1 
lib/libc/sys Makefile.inc 
share/man/man9   suser.9 
  Added files:
sys/kern kern_jail.c 
sys/sys  jail.h 
usr.sbin/jailMakefile jail.8 jail.c 
lib/libc/sys jail.2 
  Log:
  This Implements the mumbled about "Jail" feature.

-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr
FreeBSD keltia.freenix.fr 4.0-CURRENT #72: Mon Jul 12 08:26:43 CEST 1999



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

Adding disks -the pain. Also vinum

[Stephen Hocking-Senior Programmer PGS Tensor Perth]

The people who I work for were about to junk a bunch of 6 year old disks when 
I snaffled them. Among them were 4 DEC DSP5400S (3.8GB each), with a nice 
external case. These disks had been doing duty on a boat carrying out seismic 
surveys, attached to misc. Sun workstations. These are typical of their 
vintage - full height 5 1/4" drives fast narrow SCSI2, and noisy as all 
blazes. I have them hooked up to a NCR810, as one striped FS (it's just for 
experiments, not valuable data). fdisking them was easy, but disklabelling 
them was a royal pain. I ended up editing the /etc/disktab file to add an 
appropriate label and running "disklabel -w -B /dev/rda0c DSP5400S" which 
still gives an error message, but appears to install the label. I only found 
out that it installed the label by accident, wasting a bunch of time in the 
process.

I created a striped volume across the 4 drives with the default stripe size of 
256K. I read the rather interesting discussion within the man pages about the 
optimal stripe size and have a couple of queries. Firstly, the type of traffic 
that this 13.9GB filesystem will see will be mainly sequential reading and 
writing of large files. There will only be a few files (~2-30), each several 
gigs. (I'm fooling around with the seismic software at home, and typcal 
surveys can results in files many gigs in size). Given that FreeBSD breaks 
I/Os down into 64k chunks, would having a 64k stripe size give more 
parallelism? I'm seeing 4.4MB/s if I read from an individual disk, but only 
about 5.6MB/s when reading from the striped volume. Looking at the systat 
display, the 8k fs blocks do seem to be clustered into larger requests, so I'm 
not too worried about the FS block size. What have people observed with trying 
larger FS block sizes?


Stephen
-- 
  The views expressed above are not those of PGS Tensor.

"We've heard that a million monkeys at a million keyboards could produce
 the Complete Works of Shakespeare; now, thanks to the Internet, we know
 this is not true."Robert Wilensky, University of California




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

Re: Adding disks -the pain. Also vinum

[Greg Lehey]

On Tuesday,  3 August 1999 at 11:11:39 +0800, Stephen Hocking-Senior Programmer 
PGS Tensor Perth wrote:
> The people who I work for were about to junk a bunch of 6 year old disks when
> I snaffled them. Among them were 4 DEC DSP5400S (3.8GB each), with a nice
> external case. These disks had been doing duty on a boat carrying out seismic
> surveys, attached to misc. Sun workstations. These are typical of their
> vintage - full height 5 1/4" drives fast narrow SCSI2, and noisy as all
> blazes. I have them hooked up to a NCR810, as one striped FS (it's just for
> experiments, not valuable data). fdisking them was easy, but disklabelling
> them was a royal pain. I ended up editing the /etc/disktab file to add an
> appropriate label and running "disklabel -w -B /dev/rda0c DSP5400S" which
> still gives an error message, but appears to install the label. I only found
> out that it installed the label by accident, wasting a bunch of time in the
> process.

Did you try 'disklabel -w da0 auto'?

> I created a striped volume across the 4 drives with the default stripe size of
> 256K. I read the rather interesting discussion within the man pages about the
> optimal stripe size and have a couple of queries. Firstly, the type of traffic
> that this 13.9GB filesystem will see will be mainly sequential reading and
> writing of large files. There will only be a few files (~2-30), each several
> gigs. (I'm fooling around with the seismic software at home, and typcal
> surveys can results in files many gigs in size). Given that FreeBSD breaks
> I/Os down into 64k chunks, would having a 64k stripe size give more
> parallelism?

No, it would cause a higher I/O load.  Vinum doesn't transfer entire
stripes, it transfers what you ask for.  With a large stripe size, the
chances are higher that you can perform the transfer with only a
single I/O.

> I'm seeing 4.4MB/s if I read from an individual disk, but only about
> 5.6MB/s when reading from the striped volume. 

How many concurrent processes?  Remember that striping doesn't buy you
anything with a single process.  You might like to try rawio
(ftp://ftp.lemis.com/pub/rawio.tar.gz) and see what that tells you.

> Looking at the systat display, the 8k fs blocks do seem to be
> clustered into larger requests, so I'm not too worried about the FS
> block size. What have people observed with trying larger FS block
> sizes?

I don't know if anybody has tried larger FS blocks than 8 kB.  I once
created a file system with 256 kB blocks (just to see if it could be
done).  I also tried 512 kB blocks, but newfs died of an overflow.
I'd expect that you would see a marked drop in performance, assuming
that it would work at all.

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


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

Re: Adding disks -the pain. Also vinum

[Stephen Hocking-Senior Programmer PGS Tensor Perth]

 
> Did you try 'disklabel -w da0 auto'?

Yup - it also complained.

 
> No, it would cause a higher I/O load.  Vinum doesn't transfer entire
> stripes, it transfers what you ask for.  With a large stripe size, the
> chances are higher that you can perform the transfer with only a
> single I/O.

Even if I'm using really large reads?
> 
> > I'm seeing 4.4MB/s if I read from an individual disk, but only about
> > 5.6MB/s when reading from the striped volume. 
> 
> How many concurrent processes?  Remember that striping doesn't buy you
> anything with a single process.  You might like to try rawio
> (ftp://ftp.lemis.com/pub/rawio.tar.gz) and see what that tells you.

OK, I was just using good ol' dd, with dd if=/cfs/foo of=/dev/null bs=2m

> 
> > Looking at the systat display, the 8k fs blocks do seem to be
> > clustered into larger requests, so I'm not too worried about the FS
> > block size. What have people observed with trying larger FS block
> > sizes?
> 
> I don't know if anybody has tried larger FS blocks than 8 kB.  I once
> created a file system with 256 kB blocks (just to see if it could be
> done).  I also tried 512 kB blocks, but newfs died of an overflow.
> I'd expect that you would see a marked drop in performance, assuming
> that it would work at all.
> 

OK. The minimum data size read from these files tends to be about 10k. I'll 
have to try this all with a real app.


Stephen
-- 
  The views expressed above are not those of PGS Tensor.

"We've heard that a million monkeys at a million keyboards could produce
 the Complete Works of Shakespeare; now, thanks to the Internet, we know
 this is not true."Robert Wilensky, University of California




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

Re: Jail syscalls

[Brian F. Feldman]

On Tue, 3 Aug 1999, Ollivier Robert wrote:
> 
> It will probably not be very easy putting this into 3.x, considering the
> number of files concerned although the number of lines changed is not that
> big.

Jail is in RELENG_3

> -- 
> Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr
> FreeBSD keltia.freenix.fr 4.0-CURRENT #72: Mon Jul 12 08:26:43 CEST 1999
> 

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



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

Re: Adding disks -the pain. Also vinum

[Bernd Walter]

On Tue, Aug 03, 1999 at 01:35:54PM +0930, Greg Lehey wrote:
> On Tuesday,  3 August 1999 at 11:11:39 +0800, Stephen Hocking-Senior 
> Programmer PGS Tensor Perth wrote:
> 
> No, it would cause a higher I/O load.  Vinum doesn't transfer entire
> stripes, it transfers what you ask for.  With a large stripe size, the
> chances are higher that you can perform the transfer with only a
> single I/O.
> 
If you use n*64K stripes a UFS/FFS should never access 2 disks at once.

> > Looking at the systat display, the 8k fs blocks do seem to be
> > clustered into larger requests, so I'm not too worried about the FS
> > block size. What have people observed with trying larger FS block
> > sizes?
> 
> I don't know if anybody has tried larger FS blocks than 8 kB.  I once
> created a file system with 256 kB blocks (just to see if it could be
> done).  I also tried 512 kB blocks, but newfs died of an overflow.
> I'd expect that you would see a marked drop in performance, assuming
> that it would work at all.

AFAIK the limit is 64k because clustering is limitited to 64k and the fs
don't seem to handle it well.
I'm using 64k very often, because my growfs tool is already able with
this blocksize to grow a ffs over 1Tb.

-- 
B.Walter  COSMO-Project  http://www.cosmo-project.de
ti...@cicely.de Usergroupi...@cosmo-project.de



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

Re: Documenting writev(2) ENOBUFS error

[Wes Peters]

Nik Clayton wrote:
> 
> On Sat, Jul 31, 1999 at 06:50:09PM -0600, Wes Peters wrote:
> > So, do you want to enumerate the cases in which this error can occur in the
> > man page?  This is not generally done, now that we have verified it is
> > possible for the system to generate ENOBUFS on a writev.  I think the text
> > stands as it is.
> 
> FWIW, I committed:
> 
> [ENOBUFS]The mbuf pool has been completely exhausted when writing to
>  a socket

Mmmm.  Yummy.

Do we want to mention that one or more of the vectors may have been written
before the failure occurred, or is that OTTMCO?  ;^)

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

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


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

Re: Adding disks -the pain. Also vinum

[Bernd Walter]

On Tue, Aug 03, 1999 at 12:16:06PM +0800, Stephen Hocking-Senior Programmer PGS 
Tensor Perth wrote:
>  
> > No, it would cause a higher I/O load.  Vinum doesn't transfer entire
> > stripes, it transfers what you ask for.  With a large stripe size, the
> > chances are higher that you can perform the transfer with only a
> > single I/O.
> 
> Even if I'm using really large reads?
Several month ago I beleaved the same but there are severall points here:
 - UFS/FFS don't handle clustering over 64k
 - modern harddisks do preread simply by having a reversed sector layout.
 - without spindle syncronisation you will have additional latency
 - vinum don't aggregate access to subdisks, so the transfer to the subdisks
   is limited by the stripe size.

For UFS/FFS there is nothing worth seting the stripesize to low.
It is generally slower to acces 32k on different HDDs than to acces 64k on
one HDD.
Spindle Sycronisation won't bring you that much on modern HDDs - I tried
it using 5 Seagate Elite 2.9G (5,25" Full-Height).
There was no win using FFS.

If you need performance try softupdates.
At least for writing it should benefit much from striped partitions.
I never realy measured but I was astounished that you can have over 800
transactions/sec on a ccd with 6 striped disks.

-- 
B.Walter  COSMO-Project  http://www.cosmo-project.de
ti...@cicely.de Usergroupi...@cosmo-project.de



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

Re: Jail syscalls

[Ollivier Robert]

According to Brian F. Feldman:
> Jail is in RELENG_3

Not according to the CVS logs which lists kern_jail.c only for CURRENT.

===
File: kern_jail.c   Status: Up-to-date

   Working revision:1.3 Fri Apr 30 06:51:51 1999
   Repository revision: 1.3 
/spare/FreeBSD-current/src/sys/kern/kern_jail.c,v
   Sticky Tag:  (none)
   Sticky Date: (none)
   Sticky Options:  (none)

   Existing Tags:
POST_VFS_BIO_NFS_PATCH  (revision: 1.3)
PRE_VFS_BIO_NFS_PATCH   (revision: 1.3)

-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr
FreeBSD keltia.freenix.fr 4.0-CURRENT #72: Mon Jul 12 08:26:43 CEST 1999



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)

[Wes Peters]

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.
> 
> Will do.
> 
> 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.

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

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


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

Re: Mentioning RFC numbers in /etc/services

[Brian Somers]

> In message <199908022217.xaa02...@keep.lan.awfulhak.org> Brian Somers writes:
> : Yes, but do it the other way 'round - strtol first, if it's not all 
> : numeric, getservbyname().
> 
> I did it getservbyname first in case there were any legacy services
> that were all numbers.  Traditionally, this is hwo things were done
> with IP addresses, although a quickie survey shows it to be a mixed
> bag.  The biggest reason for not doing getservbyname first is that it
> will hang (long timeout) if the databsae behind it goes away.

Exactly - ditto for gethostbyname().  In the case of gethostbyname(), 
I believe that domain names can't have a number as the first 
character - I would have thought this idea should follow through with 
services.

I know I'd be pretty annoyed if I tried to do something like ``ssh -p 
1234 somewhere'' after configuring my interface in single-user modem 
with nis in /etc/host.conf and found that ssh was looking up 1234 in 
/etc/services.  Even if this is right, it's not intuitive.

> Warner

-- 
Brian 
     
Don't _EVER_ lose your sense of humour !  




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

Re: Mentioning RFC numbers in /etc/services

[Brian Somers]

> In some email I received from Brian Somers, sie wrote:
> [.]
> > Yes, but do it the other way 'round - strtol first, if it's not all 
> > numeric, getservbyname().
> 
> No, the patch was correct.

Not in my book - see my other posting :]

-- 
Brian 
     
Don't _EVER_ lose your sense of humour !  




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

Re: Adding disks -the pain. Also vinum

[Greg Lehey]

On Tuesday,  3 August 1999 at  8:12:17 +0200, Bernd Walter wrote:
> On Tue, Aug 03, 1999 at 12:16:06PM +0800, Stephen Hocking-Senior Programmer 
> PGS Tensor Perth wrote:
>>
>>> No, it would cause a higher I/O load.  Vinum doesn't transfer entire
>>> stripes, it transfers what you ask for.  With a large stripe size, the
>>> chances are higher that you can perform the transfer with only a
>>> single I/O.
>>
>> Even if I'm using really large reads?
> Several month ago I beleaved the same but there are severall points here:
>  - UFS/FFS don't handle clustering over 64k
>  - modern harddisks do preread simply by having a reversed sector layout.
>  - without spindle syncronisation you will have additional latency
>  - vinum don't aggregate access to subdisks, so the transfer to the subdisks
>is limited by the stripe size.

Note, BTW, that this wouldn't make much sense.  To aggregate access to
consecutive stripes, your transfer would have to involve *all* the
disks in the stripe set, which would be a ridiculous performance hit.
Read http://www.lemis.com/vinum/Performance-issues.html for more
details.

> For UFS/FFS there is nothing worth seting the stripesize to low.
> It is generally slower to acces 32k on different HDDs than to acces 64k on
> one HDD.

It is always slower where the positioning time is greater than the
transfer time for 32 kB.  On modern disks, 32 kB transfer in about 300
µs.  The average rotational latency of a disk running at 10,800 rpm is
2.8 ms, and even with spindle synchronization there's no way to avoid
rotational latency under these circumstances.

> Spindle Sycronisation won't bring you that much on modern HDDs - I tried
> it using 5 Seagate Elite 2.9G (5,25" Full-Height).

It should be useful for RAID-3 and streaming video.

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


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

Re: Mentioning RFC numbers in /etc/services

[Warner Losh]

In message <199908030624.haa00...@keep.lan.awfulhak.org> Brian Somers writes:
: Exactly - ditto for gethostbyname().  In the case of gethostbyname(), 
: I believe that domain names can't have a number as the first 
: character - I would have thought this idea should follow through with 
: services.

No.  That is in error.  3com.com or 2112.com.  See RFC 1123 for the
loosening of the restriction.  You have to parse the whole string to
know if it is a valid IP address or not anyway.

: I know I'd be pretty annoyed if I tried to do something like ``ssh -p 
: 1234 somewhere'' after configuring my interface in single-user modem 
: with nis in /etc/host.conf and found that ssh was looking up 1234 in 
: /etc/services.  Even if this is right, it's not intuitive.

But inetd isn't involved here at all.  You do bring up a good point
here in argument by analogy.

However your rule for isdigit(arg[0]) breaks the following services:

3com-tsmux  106/tcp
3com-tsmux  106/udp
914c/g  211/tcp#Texas Instruments 914C/G Terminal
914c/g  211/udp#Texas Instruments 914C/G Terminal
9pfs564/tcp#plan 9 file service
9pfs564/udp#plan 9 file service
3l-l1   1511/tcp
3l-l1   1511/udp
3ds-lm  1538/tcp
3ds-lm  1538/udp
3m-image-lm 1550/tcp#Image Storage license manager 3M Company
3m-image-lm 1550/udp#Image Storage license manager 3M Company

at least we know there are no all numeric service names in the
standard /etc/services file.

Warner


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

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

John-Mark Gurney <[EMAIL PROTECTED]> writes:
> Sheldon Hearn scribbled this message on Aug 1:
> > Would you need these entries if inetd let you specify port numbers
> > instead of service names?
> I vote for allowing inetd.conf to specify a port number instead of a
> service name...  it should be very easy to make the modification, and
> I'm willing to do all the work, assuming no one on -committers objects..

The correct way to do this is to fix getservbyname() so it accepts
port numbers.

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


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

confusion about nfsm_srvmtofh bad behavior?

[Alfred Perlstein]

ok:

#define nfsm_srvmtofh(f) \
{ int fhlen = NFSX_V3FH; \
if (nfsd->nd_flag & ND_NFSV3) { \
nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
fhlen = fxdr_unsigned(int, *tl); \
if (fhlen == 0) { \
bzero((caddr_t)(f), NFSX_V3FH); \
} else if (fhlen != NFSX_V3FH) { \
error = EBADRPC; \
nfsm_reply(0); \
} \
} \
if (fhlen != 0) { \
nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
if ((nfsd->nd_flag & ND_NFSV3) == 0) \
nfsm_adv(NFSX_V2FH - NFSX_V3FH); \
} \
}

notice the bcopy?  i don't really understand why we always
seem to copy 64 bytes (NFSX_V3FH), isn't this a bug?

NFSX_V3FH is 64 right?

my understanding of the code is as follows:

---
fhlen set to 64,

if we are using NFS3, extract the size of the handle from the mbufs
  if it's not valid abort with an error

now advance to the data portion (the filehandle)

copy it into the file handle, but copy 64 bytes regardless
  of the value of 'fhlen', in fact if we are using NFSv2 then
  it should only copy 32 bytes no?

it then rewinds the mbuf pointers (i think) because of the
  over "dissection" above.
---

why does it do the copy, then rewind it, it seems like it knows
it's doing something wrong and instead of fixing it, it just 
compensates after the fact.


it would have been nice if some of the variables used here
were more than 3 charaters and there was a comment or two
sprinkled about.

the code is actually pretty nifty and makes sense, but you need
to stare at it for a few hours before you can make heads or
tails of anything.  the fact that nested macros used modify
variables in the calling function is really, urm... cool? :)


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



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

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On 02 Aug 1999 13:05:17 +0200, Dag-Erling Smorgrav wrote:

> The correct way to do this is to fix getservbyname() so it accepts
> port numbers.

Would this not still require modifications to /etc/services for services
not already mentioned in that file?

Ciao,
Sheldon.


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

Re: Proposing argv for klds and preloaded modules

[Boris Popov]

On Sun, 1 Aug 1999, Chris Costello wrote:

> On Sun, Aug 01, 1999, Juha Nurmela wrote:
> >
> > Sometimes it would be handy to pass a commandline
> > to a kld, preloaded modules already support
> > arguments. kldload(2) unfortunately has only
> > the pathname.ko argument.
> 
>Is this really a problem?  Can the administrator not use
> sysctl instead?

It is not always possible. Some device drivers (both hardware and
software) require an arguments that needed at init/attach time.

IMO, args should be passed in usual manner via argv[] and
argc with plain get_opt() in libkern.

--
Boris Popov
http://www.butya.kz/~bp/



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

Re: Mentioning RFC numbers in /etc/services

[Daniel Eischen]

Dag-Erling Smorgrav wrote:
> John-Mark Gurney <[EMAIL PROTECTED]> writes:
> > Sheldon Hearn scribbled this message on Aug 1:
> > > Would you need these entries if inetd let you specify port numbers
> > > instead of service names?
> > I vote for allowing inetd.conf to specify a port number instead of a
> > service name...  it should be very easy to make the modification, and
> > I'm willing to do all the work, assuming no one on -committers objects..
> 
> The correct way to do this is to fix getservbyname() so it accepts
> port numbers.

Are you sure this is what you want?  It may allow an application to
use a port number that would otherwise be invalid.

Dan Eischen
[EMAIL PROTECTED]


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

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

Sheldon Hearn <[EMAIL PROTECTED]> writes:
> On 02 Aug 1999 13:05:17 +0200, Dag-Erling Smorgrav wrote:
> > The correct way to do this is to fix getservbyname() so it accepts
> > port numbers.
> Would this not still require modifications to /etc/services for services
> not already mentioned in that file?

Allow me to re-quote the message I answered:

> I vote for allowing inetd.conf to specify a port number instead of a
> service name...

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


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

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On 02 Aug 1999 13:19:01 +0200, Dag-Erling Smorgrav wrote:

> > Would this not still require modifications to /etc/services for services
> > not already mentioned in that file?
> 
> Allow me to re-quote the message I answered:
> 
> > I vote for allowing inetd.conf to specify a port number instead of a
> > service name...

I think that's exactly what Daniel's getting at.

If we fix this in inetd, we get what we want. If we fix this in
getservbyport() we may get something that we don't want, namely
applications that relay on the existing behaviour of the function stop
working as intended.

Ciao,
Sheldon.


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

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

Daniel Eischen <[EMAIL PROTECTED]> writes:
> Dag-Erling Smorgrav wrote:
> > The correct way to do this is to fix getservbyname() so it accepts
> > port numbers.
> Are you sure this is what you want?

Yes.

>  It may allow an application to
> use a port number that would otherwise be invalid.

Please elaborate.

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


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

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On Sat, 31 Jul 1999 23:00:15 MST, Doug wrote:

> > Would you need these entries if inetd let you specify port numbers
> > instead of service names?
>
>   Errr... while that may be of value to someone, it has nothing to
> do with the issue Ben and I were discussing.

Yes yes. I'm not trying to contribute to the conversation you're having.
I'm trying to get your opinion on an issue that came up during your
conversation. :-)

Ciao,
Sheldon.


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

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On 02 Aug 1999 13:27:44 +0200, Dag-Erling Smorgrav wrote:

> I don't see in what way an application could break if getservbyname()
> suddenly accepted numeric port specifications. It won't ``stop working
> as intended'', it'll keep on working as it always used to, plus a
> little more.

My application limits the port numbers it'll play with based on what's
in /etc/services, since getservbyname() implies this limitation.

Administrators rely on the fact that only root can play with
/etc/services so that this silly application can't play with ports that
aren't in that file.

No getservbyname() doesn't work the way it used to, and the
administrator is shot in the foot, even though he didn't pull the
trigger.

Ciao,
Sheldon.


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

Re: Mentioning RFC numbers in /etc/services

[Daniel Eischen]

Dag-Erling Smorgrav wrote:
> >  It may allow an application to
> > use a port number that would otherwise be invalid.
>
> Please elaborate.

I don't have any specific applications in mind :)  But suppose an
application (for whatever reason) only wants to allow selection of
certain service names.  A user could type in any port number that
was in /etc/services, and the application would use it.

Are you also going to allow getservbyport to lookup names?

Dan Eischen
[EMAIL PROTECTED]


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

Re: confusion about nfsm_srvmtofh bad behavior?

[Alfred Perlstein]

On Mon, 2 Aug 1999, Alfred Perlstein wrote:

>   } \
>   if (fhlen != 0) { \
>   nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
>   bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
>   if ((nfsd->nd_flag & ND_NFSV3) == 0) \
>   nfsm_adv(NFSX_V2FH - NFSX_V3FH); \
>   } \
>   }

...

> it then rewinds the mbuf pointers (i think) because of the
>   over "dissection" above.
> ---
> 
> why does it do the copy, then rewind it, it seems like it knows
> it's doing something wrong and instead of fixing it, it just 
> compensates after the fact.

yes, replying to my own message.

the only thing i can think of is that the extra data is safely
ignored because the routines that use these macros seem to
pass the version of NFS to all the function that they call...

however unless i'm wrong (which i probably am) nfsV2 stuff
could be made faster if it was correctly noted and less data
was copied.  It would also DTRT and not access data it isn't
supposed to :)

it seems like all of the V3 handles are the same length so
there isn't much to do there...

-Alfred



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

Re: Mentioning RFC numbers in /etc/services

[Daniel Eischen]

Daniel Eischen wrote:
> Are you also going to allow getservbyport to lookup names?   

Stupid question.  This isn't possible since getservbyport takes
an int argument.

Dan Eischen
[EMAIL PROTECTED]


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

Re: Mentioning RFC numbers in /etc/services

[Sheldon Hearn]

On Mon, 02 Aug 1999 07:30:32 -0400, Daniel Eischen wrote:

> Are you also going to allow getservbyport to lookup names?

And how are you going to squish a name into an int? :-)

Ciao,
Sheldon.


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

Re: Mentioning RFC numbers in /etc/services

[Dag-Erling Smorgrav]

Sheldon Hearn <[EMAIL PROTECTED]> writes:
> If we fix this in inetd, we get what we want. If we fix this in
> getservbyport() we may get something that we don't want, namely
> applications that relay on the existing behaviour of the function stop
> working as intended.

I don't see in what way an application could break if getservbyname()
suddenly accepted numeric port specifications. It won't ``stop working
as intended'', it'll keep on working as it always used to, plus a
little more. It'll also make it a darn sight easier to parse port
specifications e.g. from the command line.

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


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

A Proposal for a Consumers' Private Network with Providers

[Richard Auld]

Aug. 2, 1999.
Dear Sir or 
Ms:
    
This notification is being sent to a selected group of 
consumer-oriented organizations and individuals that I believe will be 
interested, and that I hope can help with advice on how best 
to proceed with a proposal that I feel certain can be of very great 
benefit to consumers world wide.
    
The proposal is covered in some detail on a Web site that has recently 
been posted, and which has not yet been promoted in the normal ways, 
so only the recipients of this notification should be aware of it's 
existence at this point.  Briefly, the proposal is for 
a Virtual Private Network, to be composed of a world wide Extranet that 
links many small local area Intranets (e.g., USA=47,000 zipcode areas, max.) to 
be owned and operated by consumer co-ops.  The Extranet would be 
operated by a world wide Federation of these local area 
co-ops.
    
The benefits for the members of these co-ops would be numerous, and 
non-member consumers would benefit also, in accordance with co-op 
traditions.  The Web site describes the origins of these benefits in some 
detail.
    
My primary concern at this point is how best to proceed for the good of all 
consumers.  I am a retired business systems analyst and 
programmer, not an experienced cooperative business developer, and I especially 
want to avoid inadvertently doing anything that might jeopardize a major 
cause for which I am proposing this network ~ that of a world 
wide Federation of consumer co-ops.
   I 
firmly believe that, for reasons both technical and otherwise, now is the 
time for this proposal to be implemented.  I believe I 
am competent to undertake the direction of many of the software 
development tasks that would be required to implement this 
network, but beyond that narrowly technical area, I am in the learning 
mode, at best, especially regarding the financial/legal issues and 
options involved.
So, if you and your associates feel that this 
proposal has at least some of the outstanding merit that I claim for it in the 
book-format Web site, I would be both open to and very appreciative of 
suggestions and/or business proposals as to how best to proceed with it's 
development, including any design revisions that you may deem 
advisable.  Please consider the rather amateurish business 
development plans mentioned in the proposal as separate from the proposed 
network and software design concepts, which I now believe to be both technically 
feasible and to have at least  adequate functionality, at 
least for discussion and detailed improvements, if not for actual network 
startup purposes.
    The Web site is 
accessible from my Netopia virtual office by simply selecting "Wisdom, Inc." on 
the "office door".  You will also notice on the office door 
there a diagram of the proposed network architecture.  That diagram and 
it's accompanying text is the first slide 
of a presentation that was prepared for consumers in 
general, and the remainder of the show is accessed by selecting the 
"Pictures" button to the upper left.  The help facility shows fairly 
complete instructions, but if you have any questions or wish to 
speak to me personally, please contact me at any time by selecting 
"Conference" ~ the "Intercom" is an internet telephone.  Text 
chat and MS NetMeeting-compatible group interactions are facilitated in the 
conference room also.
    
Thank You for your help!

  
CLICK Here to visit my Netopia Virtual 
Office
   Co-operatively 
Yours,
   Richard J. 
Auld
    3421 
Ivanhoe Lane
    
Garland, TX 75044
    
972-414-0295  
 smiling.gif
 GreenLightBG1.jpg

Re: Mentioning RFC numbers in /etc/services

[Matthew Dillon]

:John-Mark Gurney <[EMAIL PROTECTED]> writes:
:> Sheldon Hearn scribbled this message on Aug 1:
:> > Would you need these entries if inetd let you specify port numbers
:> > instead of service names?
:> I vote for allowing inetd.conf to specify a port number instead of a
:> service name...  it should be very easy to make the modification, and
:> I'm willing to do all the work, assuming no one on -committers objects..
:
:The correct way to do this is to fix getservbyname() so it accepts
:port numbers.
:
:DES
:-- 
:Dag-Erling Smorgrav - [EMAIL PROTECTED]

If we were to depend on this, it would break code compatibility with 
other UNIXes for no good reason.   For example, someone porting inetd
from FreeBSD to something else would not get a compatible result without
undoing the 'fix'.

'Fixing' getservbyname() is a really bad idea.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: So, back on the topic of enabling bpf in GENERIC...

[Josef Karthauser]

On Sun, Aug 01, 1999 at 10:17:54AM -0400, Sergey Babkin wrote:
> Warner Losh wrote:
> > 
> > In message <[EMAIL PROTECTED]> Wes Peters writes:
> > : Do we have a list of all services that use bpf?  I'm willing to edit the man
> > : pages, given a list.  I guess I could just grep-o-matic here, huh?
> > 
> > Yes.  I'm also in a holding off pattern until we know the exact impact
> > for all daemons that use this...
> 
> I think I found a solution that may be better (although more complicated):
> 
> Let the sysadmin to define a bpf filter for the packets that are considered
> OK (say, DHCP or RARP or RBOOT or whatever else this installation needs for
> normal functioning). Provide some typical examples.
> 
> After this filter is defined and the system goes to a higher security
> level bpf first applies this filter to all the incoming packets, and only
> if they pass this filter they are checked for application-specified filters.
> If there is no such "master" filter defined then bpf can just deny
> new open()s as proposed earlier. This will allow the applications to 
> use bpf but only for the purposes defined in the master filter. This 
> also resolves the problem of services re-opening bpf after SIGHUP.
> 

I like this.  I'd prefer the default to be that bpf forwards all
packets, unless there is a template filter defined.  I see no reason
to change access to bpf at higher secure levels, because a master
filter can be installed at boot time to do this work.  Of course
we may have an equivalent of 'IPFIREWALL_DEFAULT_TO_ACCEPT' to
accomodate this.

Joe
-- 
Josef KarthauserFreeBSD: How many times have you booted today?
Technical Manager   Viagra for your server (http://www.uk.freebsd.org)
Pavilion Internet plc.  [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]]


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

Re: readdirplus is very cool, any other nfs client suggestions?

[Matthew Dillon]

:Alfred Perlstein <[EMAIL PROTECTED]> writes:
:> DES: can you elaborate?  you think it may cause problems with amd
:> since it's like an NFS buffer isn't it and would work over the 
:> loopback...
:
:I used loopback mounts to test NFS make worlds a while ago (there were
:places where make world would bomb because chflags doesn't work on
:NFS) and experienced deadlock problems. Somebody (I don't remember who
:exactly) told me that this was a known problem with the NFSv3 code;
:reading over loopback mounts works fine, but writing apparently
:results in deadlocks. Search the archives; the commit logs should give
:you an idea of when this was (check the logs for Makefiles that use
:chflags).
:
:root@des ~# current -l -F Makefile chflags 
:src/Makefile.inc1
:src/lib/libc/sys/Makefile.inc
:src/lib/libc_r/Makefile
:src/release/Makefile
:src/sys/alpha/conf/Makefile.alpha
:src/sys/i386/conf/Makefile.i386
:src/sys/pc98/conf/Makefile.pc98
:src/usr.bin/Makefile
:src/usr.bin/chflags/Makefile
:src/usr.bin/chpass/Makefile
:src/usr.bin/passwd/Makefile
:
:DES
:-- 
:Dag-Erling Smorgrav - [EMAIL PROTECTED]

The buildworld chflags problems were fixed around a month ago I think.
Since then there have been many NFS fixes committed.  I have not tested
running buildworld over a loopbacked NFS mount -- I'll do that today --
but I'd say there is a good chance that it will simply work.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: confusion about nfsm_srvmtofh bad behavior?

[Matthew Dillon]

:On Mon, 2 Aug 1999, Alfred Perlstein wrote:
:
:>  } \
:>  if (fhlen != 0) { \
:>  nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
:>  bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
:>  if ((nfsd->nd_flag & ND_NFSV3) == 0) \
:>  nfsm_adv(NFSX_V2FH - NFSX_V3FH); \
:>  } \
:>  }
:
:...
:
:> it then rewinds the mbuf pointers (i think) because of the
:>   over "dissection" above.
:> ---
:> 
:> why does it do the copy, then rewind it, it seems like it knows
:> it's doing something wrong and instead of fixing it, it just 
:> compensates after the fact.
:
:yes, replying to my own message.
:
:the only thing i can think of is that the extra data is safely
:ignored because the routines that use these macros seem to
:pass the version of NFS to all the function that they call...
:
:however unless i'm wrong (which i probably am) nfsV2 stuff
:could be made faster if it was correctly noted and less data
:was copied.  It would also DTRT and not access data it isn't
:supposed to :)
:
:it seems like all of the V3 handles are the same length so
:there isn't much to do there...
:
:-Alfred

Well, I must say that it certainly looks like a bug.  It is not going
to blow anything up since the nfsm_dissect() will break out if it runs
out of buffer space, but it certainly seems inefficient.  I am somewhat 
loath to fix anything in NFS that does not create a demonstrateable
problem for fear of creating new problems, though, it is quite possible
that the server code depends on the extra junk in the file handle for
V2 mounts - A full audit of nfs_nqlease.c and nfs_serv.c would be
necessary before this could be fixed.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: confusion about nfsm_srvmtofh bad behavior?

[Matthew Dillon]

::> it then rewinds the mbuf pointers (i think) because of the
::>   over "dissection" above.
::> ---
::> 
::> why does it do the copy, then rewind it, it seems like it knows
::> it's doing something wrong and instead of fixing it, it just 
::> compensates after the fact.
::
::yes, replying to my own message.
::
::the only thing i can think of is that the extra data is safely
::ignored because the routines that use these macros seem to
::pass the version of NFS to all the function that they call...
::
::however unless i'm wrong (which i probably am) nfsV2 stuff
::could be made faster if it was correctly noted and less data
::was copied.  It would also DTRT and not access data it isn't
::supposed to :)
::
::it seems like all of the V3 handles are the same length so
::there isn't much to do there...
::
::-Alfred
:
:Well, I must say that it certainly looks like a bug.  It is not going
:to blow anything up since the nfsm_dissect() will break out if it runs
:out of buffer space, but it certainly seems inefficient.  I am somewhat 
:loath to fix anything in NFS that does not create a demonstrateable
:problem for fear of creating new problems, though, it is quite possible
:that the server code depends on the extra junk in the file handle for
:V2 mounts - A full audit of nfs_nqlease.c and nfs_serv.c would be
:necessary before this could be fixed.
:
:   -Matt
:   Matthew Dillon 
:   <[EMAIL PROTECTED]>

Oh, p.s.  But in the mean time, if you or someone would like to commit
an XXX comment to document the potential bug / performance problem, I
think that would be very appropriate.  e.g.

/*
 * Extract file handle from NFS stream.   XXX note that the extraction of
 * the file handle for an NFSv2 mount appears to be rather odd.  It is copying
 * NFSX_V3FH bytes instead of NFSX_V2FH and then rewinding the mbuf index.
 */
 
#define nfsm_srvmtofh(f) \
{ int fhlen = NFSX_V3FH; \
if (nfsd->nd_flag & ND_NFSV3) { \
nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
fhlen = fxdr_unsigned(int, *tl); \
...

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: readdirplus is very cool, any other nfs client suggestions?

[Tim Vanderhoek]

On Mon, Aug 02, 1999 at 09:25:52AM +0200, Dag-Erling Smorgrav wrote:
>(there were
> places where make world would bomb because chflags doesn't work on
[...]
>  (check the logs for Makefiles that use
> chflags).
[...]
> root@des ~# current -l -F Makefile chflags 
> src/Makefile.inc1

Set INSTALLFLAGS_EDIT=:S/schg/,/ to remove these when doing a make
world, if needed.

[A make world actually works from usermode now with the right set of
options (one of which is -DNOGAMES)].


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


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

Re: readdirplus is very cool, any other nfs client suggestions?

[Dag-Erling Smorgrav]

Matthew Dillon <[EMAIL PROTECTED]> writes:
> The buildworld chflags problems were fixed around a month ago I think.

No, I fixed them in february or march.

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


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

Re: readdirplus is very cool, any other nfs client suggestions?

[Dag-Erling Smorgrav]

Tim Vanderhoek <[EMAIL PROTECTED]> writes:
> Set INSTALLFLAGS_EDIT=:S/schg/,/ to remove these when doing a make
> world, if needed.

Please try to understand what the issue is before butting in.

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


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

Re: readdirplus is very cool, any other nfs client suggestions?

[Matthew Dillon]

:Matthew Dillon <[EMAIL PROTECTED]> writes:
:> The buildworld chflags problems were fixed around a month ago I think.
:
:No, I fixed them in february or march.
:
:DES
:-- 
:Dag-Erling Smorgrav - [EMAIL PROTECTED]

Ok, then there is a real good chance localhost mounts will work now.

I'm running a buildworld test right now with /usr/src and /usr/obj both
on NFSv3 localhost mounts.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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