Re: Tagged Command Queuing support for IC-35L0?0 ?

[Terry Lambert]

Steve Roome wrote:
> > Can these newer drives, based on the IC-35L0?0-chipset, also be used
> > with TCQ enabled in FBSD? (? is 2, 4 or 6 depending on whether the
> > drive has 20, 40 or 60 GB capacity).
> 
> I've got one of these :
> 
> ad0: 39266MB  [79780/16/63] at ata0-master UDMA66
> 
> If I turn tagged queueing on, I get an awful lot of write failures and
> ata timeouts and whatnot. Basically it just doesn't work. **For me**
> 
> I'm not blaming Søren Schmidt here! it could be due to broken
> hardware, code or just my sheer incompetence, but in the end I gave up
> trying, it didn't work with my last drive either, and that was a 30GP
> type drive (don't remember the model number though).
> 
> As far as I remember there are apparently problems with some of these
> drives in terms of whether they even work when they leave the factory,
> but I've only ever heard that here (make what you want of that).

Search for "tagged command queueing" and "DLTA" and "IBM";
you will be rewarded with many horror storries about the
drive electronics not being able to keep up on these drives,
when writing near the spindle.  This normally doesn't happen
until the disk is almost full, with Windows FS's, which will
usually place your machine "safely" out of warranty.

-- Terry

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

Re: KLD subsystem improvement

[Warner Losh]

In message <[EMAIL PROTECTED]> "Eugene L. Vorokov" writes:
: I'm going to implement a small improvement to a KLD system. I want linker
: file not to be loaded at all when all modules inside it fail to load for
: some reasons. I think that would be logical behaviour. Does anyone think
: that such change would break something ?

kldload if_ed.ko


Would break.

Warner

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

Re: FreeBSD and Athlon Processors

[Warner Losh]

In message <[EMAIL PROTECTED]> Terry Lambert writes:
: Are you sure it's not just a CMD640 IDE controller?  They are
: known to have issues; Linux has a patch... FreeBSD used to, but
: I think it got yanked out, or was just turned off by default.

The CMD640 had many DMA corruption bugs.  Many are fixed with the
Linux patch, but data corruption issues remain.

Warner

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

Re: SO_REUSEPORT on unicast UDP sockets

[Mike Silbersack]

On Mon, 3 Sep 2001, Terry Lambert wrote:

> Similarly, there are a number of bugs in the TCP sockets as
> well; specifically, there's a problem with all sockets being
> treated as being in the same collision domain, when doing
> automatic port assignment.  This limits you to 65535 oubound
> TCP connections, even though you have multiple IP aliases on
> an interface (theoretically, you should get 64k connections
> per IP address, if you bind _not_ to IN_ADDR_ANY, but instead
> use a specific port, but the hash is broken).

I like this problem's evil sibling: client side TIME_WAITs.  If you build
them up, you just sit there unable to allocate outgoing ports until they
time out.

Maybe net or openbsd handle these situations better, I'll have to check
later.

Mike "Silby" Silbersack


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

Re: Tagged Command Queuing support for IC-35L0?0 ?

[Steve Roome]

On Tue, Sep 04, 2001 at 07:20:30PM +0200, Niek Bergboer wrote:
> Can these newer drives, based on the IC-35L0?0-chipset, also be used
> with TCQ enabled in FBSD? (? is 2, 4 or 6 depending on whether the
> drive has 20, 40 or 60 GB capacity).

I've got one of these :

ad0: 39266MB  [79780/16/63] at ata0-master UDMA66

If I turn tagged queueing on, I get an awful lot of write failures and
ata timeouts and whatnot. Basically it just doesn't work. **For me**

I'm not blaming Søren Schmidt here! it could be due to broken
hardware, code or just my sheer incompetence, but in the end I gave up
trying, it didn't work with my last drive either, and that was a 30GP
type drive (don't remember the model number though).

As far as I remember there are apparently problems with some of these
drives in terms of whether they even work when they leave the factory,
but I've only ever heard that here (make what you want of that).

Good luck, YMMV I think I might have made a local patch to include
my drive.. something like this...

/usr/src/sys/dev/ata/ata-disk.c around line 861
   const char *drives[] = {"IBM-DPTA", "IBM-DTLA", "IC35L040AVER07", NULL};

As I said, it didn't work though =(

Steve

P.S. let me know if you suceed in getting it to work, maybe I need a
different motherboard or just to change some settings or something?

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

Re: Should URL's be pervasive.

[Kevin Way]

On Tue, Sep 04, 2001 at 07:08:44PM -0500, Mike Meyer wrote:
> Kevin Way <[EMAIL PROTECTED]> types:
> > I'm quite sure that Mr. Sinz wasn't suggesting that telnet smtp://localhost
> > should do something useful.  Nor do I consider his idea "lazy".  I do think
> > that he was suggesting, and I concur, that there's no logical reason that
> > networked file access should be treated differently by user applications
> > than local file access.
> 
> I would concur with that, so long as you remember that "local file
> access" involves someone making usually-privileged system calls to
> arrange to map those remote name spaces into the local name
> space. That is different from making URLs pervasive.

Agreed.  You'll notice I agreed with Michael Sinz's post, not the
pro-URL posts.  I like the idea of being able to say...

mount -t http http://www.freebsd.org/ /www/freebsd
cat /www/freebsd/doc/en_US.ISO8859-1/books/faq/index.html

even a simple example like 'cat http://www.freebsd.org/' seems nice, but it
raises as more questions than it answers.

Obviously protocols which are not file oriented won't translate effectively
into filesystems.  mailto is an excellent example of a scheme that doesn't
translate effectively into a filesystem translation layer.  I'd have no idea
what to do with a mailto url, or how to reference it as a filesystem.

Combine the above filesystem concept with something like amd, and many
activities become extremely convenient.

> > I strongly suggest you read his post again, and think about how nice it is
> > for a moment that you can mount CODA, 9660, NFS, FFS, UFS, FAT, NTFS, SMBFS,
> > etc and have user-level programs access their data in exactly the same 
> > manner.
> 
> Those are all file systems, and operations on the things on them all
> have pretty much the same semantics. This isn't true for URLs in
> general.

Agreed.

> It's true for some subset of the available schemes, and don't think anyone
> would object to file system modules for ftp or http. 

this is what the post I agred with was suggesting.  this is what i believe
would be a good idea.

> You can even do this in userland with an nfs server API if you
> want it to be portable.

Novel idea.  I'll file it into the maybe pile.

> I don't know of any application that handles local files that responds
> to any open error by prompting for a password. If "open" can now
> return an HTTP 401 error, every application is going to need to be
> able to deal with that in some sane way. Either that, or users are
> going to have to know the proper syntax for usernames and passwords in
> every URL scheme they deal with - and start putting passwords on
> command lines, and other things that give security officers
> nightmares.

I would imagine that an http filesystem layer would return EACCES for a
401, as that would probably cause any program to return a sane error to
the user.

> > This is not an LSD-induced 'turn freebsd into windows' idea, it's a very
> > simple extension of ideas that FreeBSD already has in place.
> 
> Conceptually, it may be very simple. In practice, it's very, very
> messy. The correct thing to do with a URL is going to depend on the
> application that's doing it, what the application is doing, and the
> scheme for the URL. The application is really the only thing that can
> figure all that out. In the simplest possible example, "cat" can just
> treat appropriate URLs like files and read from them. "vi" - or
> something that vi is talking to - needs to be taught how to deal with
> streaming data in some way.

Yes, unfortunately all ideas are just a Simple Matter of Programming...
One miscommunication I should apologize for, I'm not suggesting the
URLification of FreeBSD.  I'm suggesting that it would be a Good Thing if
files available via any common networked file transfer protocol were able
to be accessed via standard system calls.

> In summary, each command needs to decide - possibly on a case-by-case
> basis whether or not the string it's got is a URL or a file name. It
> needs to decide how the operation it's been asked to be performed can
> be performed on the object that URL represents, and if so how it
> should be mapped. If it's a URL, the application may well have to deal
> with events that don't happen with local files.

I really don't want all that in every command.  I want it in a filesystem
layer, where appropriate, as described above.

Anyway, in conclusion it would seem to me that we agree, but there was a
misunderstanding because I did a poor job of clipping relevant text to
show what it was I was agreeing with.

I apologize for the miscommunication.

Kevin Way

 PGP signature

Re: Routing Performance?

[Wes Peters]

Leo Bicknell wrote:
> 
> On Mon, Sep 03, 2001 at 06:01:04PM -0600, Ronald G Minnich wrote:
> > you do know that API just layed off (almost) all their alpha people,
> > right?
> >
> > alpha is dead. Thank compaq any time.
> >
> > ron (who owns 112 Compaq Alpha boxes, and 16 API CS20s)
> 
> No I didn't.  That's really sad.

I wonder if the impending Hewlett-Compaqard merger will hasten the Alpha
into its grave.  The King is Dead, Long Live the King!

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

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

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

Re: Flow cache on FreeBSD?

[Marco Wertejuk]

Hello,

| Yes. Please go and find the NeTraMet package on the web - it should

NeTraMet is in the ports so you don't have to search it
on the web: /usr/ports/net/NeTraMet/

-- 
Mit freundlichen Gruessen,
Marco Wertejuk - mwcis.com
Computer/Internet/Security-Services

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

Re: Should URL's be pervasive.

[Mike Meyer]

Kevin Way <[EMAIL PROTECTED]> types:
> > If you're really lazy and want to be able to do:
> > telnet smtp://localhost
> > I suggest you look into this relatively new invention called 
> > '/etc/services' and read some manual pages. You'll find you can do 
> > something quite similar, and much saner.
> I'm quite sure that Mr. Sinz wasn't suggesting that telnet smtp://localhost
> should do something useful.  Nor do I consider his idea "lazy".  I do think
> that he was suggesting, and I concur, that there's no logical reason that
> networked file access should be treated differently by user applications
> than local file access.

I would concur with that, so long as you remember that "local file
access" involves someone making usually-privileged system calls to
arrange to map those remote name spaces into the local name
space. That is different from making URLs pervasive. For one thing, it
doesn't muck with the local name space. If URL's are pervasive and I
issue the comand "vi mailto:[EMAIL PROTECTED]";, am I going to
edit a file in the local directory called
mailto:[EMAIL PROTECTED], or am I going to send a mail message to
[EMAIL PROTECTED]? For another, it provides a place to hang
information that's global about that mapping - for instance, providing
uids and permission bits to handed back from file systems that don't
have them.

> I strongly suggest you read his post again, and think about how nice it is
> for a moment that you can mount CODA, 9660, NFS, FFS, UFS, FAT, NTFS, SMBFS,
> etc and have user-level programs access their data in exactly the same 
> manner.

Those are all file systems, and operations on the things on them all
have pretty much the same semantics. This isn't true for URLs in
general. It's true for some subset of the available schemes, and I
don't think anyone would object to file system modules for ftp or
http. You can even do this in userland with an nfs server API if you
want it to be portable.

However, not all URI schemes have that property. For instance, Mike
refers to emacs having "transparent FTP support". It's not really
transparent, as opening a local file never asks me for a password! If
the ftp server is mounted, then you can provide authentication
information as options to the mount. You can even deal with FTP
servers that want an ACCT command, which doesn't have a place in the
RFC 1738 ftp scheme.

I don't know of any application that handles local files that responds
to any open error by prompting for a password. If "open" can now
return an HTTP 401 error, every application is going to need to be
able to deal with that in some sane way. Either that, or users are
going to have to know the proper syntax for usernames and passwords in
every URL scheme they deal with - and start putting passwords on
command lines, and other things that give security officers
nightmares.

> This is not an LSD-induced 'turn freebsd into windows' idea, it's a very
> simple extension of ideas that FreeBSD already has in place.

Conceptually, it may be very simple. In practice, it's very, very
messy. The correct thing to do with a URL is going to depend on the
application that's doing it, what the application is doing, and the
scheme for the URL. The application is really the only thing that can
figure all that out. In the simplest possible example, "cat" can just
treat appropriate URLs like files and read from them. "vi" - or
something that vi is talking to - needs to be taught how to deal with
streaming data in some way.

Sockets are similar in many respects. In a lot of ways, sockets look
like file descriptors with some extra functions that can be applied to
them. In many cases, all you do with a socket once you've got it is
standard file descriptor calls. However, the kernel doesn't let you
just "open" a socket. Yes, there are file systems that let you treat a
subset of the possible sockets and socket operations that way. But to
take full advantage of them, you have to use a different API.

In summary, each command needs to decide - possibly on a case-by-case
basis whether or not the string it's got is a URL or a file name. It
needs to decide how the operation it's been asked to be performed can
be performed on the object that URL represents, and if so how it
should be mapped. If it's a URL, the application may well have to deal
with events that don't happen with local files.

All of which is why I think we're already moving in the right
direction. We've got a library routine that you can hand a URL to, and
it hands back FILE *. We've also got routines that will parse the URL
so you can manipulate it, for instance plugging in a new password and
user name that the application got from the user in a manner
appropriate for that application.

For some reason, this all brings to mind the request to make open act
like the Perl open.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

To Unsubscribe: s

Re: Flow cache on FreeBSD?

[Andrzej Bialecki]

Deepak Jain wrote:
> 
> Is there a way to provide functionality similar to ip flow cache stats on a
> FreeBSD router?
> 
> Let me clarify, I am talking about being able to easily see groupings of
> traffic go through a FreeBSD box. So if a downstream customer is being
> attacked, a simple table in realtime [or near real-time] will show the
> attack characteristics [ip ranges, packet types, general number of packets,
> etc].?

Yes. Please go and find the NeTraMet package on the web - it should
compile cleanly on FreeBSD (if not the latest versions, then surely some
older - I used them some time ago). It's very configurable, and comes
with a lot of examples (among others, and XWindow application to watch
the flows in real-time).

-- 

Andrzej

// 
// Andrzej Bialecki <[EMAIL PROTECTED]>, Chief System Architect
// WebGiro AB, Sweden (http://www.webgiro.com)
// 
// <[EMAIL PROTECTED]> FreeBSD developer (http://www.freebsd.org)

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

Flow cache on FreeBSD?

[Deepak Jain]

Is there a way to provide functionality similar to ip flow cache stats on a
FreeBSD router?

Let me clarify, I am talking about being able to easily see groupings of
traffic go through a FreeBSD box. So if a downstream customer is being
attacked, a simple table in realtime [or near real-time] will show the
attack characteristics [ip ranges, packet types, general number of packets,
etc].?

Thanks,

Deepak Jain
AiNET


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

Re: Should URL's be pervasive.

[Kevin Way]

> If you're really lazy and want to be able to do:
>   telnet smtp://localhost
> I suggest you look into this relatively new invention called 
> '/etc/services' and read some manual pages. You'll find you can do 
> something quite similar, and much saner.

I'm quite sure that Mr. Sinz wasn't suggesting that telnet smtp://localhost
should do something useful.  Nor do I consider his idea "lazy".  I do think
that he was suggesting, and I concur, that there's no logical reason that
networked file access should be treated differently by user applications
than local file access.

I strongly suggest you read his post again, and think about how nice it is
for a moment that you can mount CODA, 9660, NFS, FFS, UFS, FAT, NTFS, SMBFS,
etc and have user-level programs access their data in exactly the same 
manner.

This is not an LSD-induced 'turn freebsd into windows' idea, it's a very
simple extension of ideas that FreeBSD already has in place.

Kevin Way

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

Re: Question about VLAN dot1q tagging in FreeBSD

[Ulf Zimmermann]

On Tue, Sep 04, 2001 at 05:24:50PM -0400, Leo Bicknell wrote:
> On Tue, Sep 04, 2001 at 02:19:06PM -0700, Ulf Zimmermann wrote:
> > Last night I setup dot1q tagging again on another machine and had
> > the same problem. Looking into packets sent down the trunk, I saw
> > that VLAN 1 wasn't tagged (I assume the dot1q spec tells so that
> > VLAN 1 packets aren't tagged, while other VLANs are). If this is
> > right, I think we should mention this in the man page. Here is a
> > copy of the current man page of ifconfig in regards to VLAN:
> 
> It is slightly more complicated.  802.1q allows a single, untagged
> vlan to operate across a link for compatability reasons, and calls
> it the 'default' VLAN.  There is no requirement that it be VLAN 1.
> That is, you could set the default vlan to be 10 on both sides,
> and tag all the rest (including 1).  You could also set vlan 1 on
> one side, and vlan 10 on the other, and they would be bridged
> together.  Cisco devices warn when you do this (via CDP, it must
> be enabled).

All the documentation I have read lately seemed to indicated that
VLAN 1 is the one to be present, but I haven't read the dot1q
spec (time to do that (: ).

> 
> Convention seems to be that vlan 1 is the 'default vlan' on almost
> all devices.
> 
> Having better notes in a man page would be good.

We should at least put a note into the man about it, different
wording when what I had posted. I haven't checked the handbook
lately, but every time I mention dot1q tagging and FreeBSD, I 
seem to find someone who says the documentation about it is
very sparse. We might want to review that too.

I personal use it for lab setups I have done at home (been
trying to CCIE, but right now I am having a grudge against
Cisco and their supposely high quality about the tests (Lab
protoctor showed up late, didn't give the lost time at the
end, errors in the documentation of the lab, no reply from
the CCIE program so far)).

> 
> -- 
> Leo Bicknell - [EMAIL PROTECTED]
> Systems Engineer - Internetworking Engineer - CCIE 3440
> Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
> 

-- 
Regards, Ulf.

-
Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204

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

Re: Question about VLAN dot1q tagging in FreeBSD

[Leo Bicknell]

On Tue, Sep 04, 2001 at 02:19:06PM -0700, Ulf Zimmermann wrote:
> Last night I setup dot1q tagging again on another machine and had
> the same problem. Looking into packets sent down the trunk, I saw
> that VLAN 1 wasn't tagged (I assume the dot1q spec tells so that
> VLAN 1 packets aren't tagged, while other VLANs are). If this is
> right, I think we should mention this in the man page. Here is a
> copy of the current man page of ifconfig in regards to VLAN:

It is slightly more complicated.  802.1q allows a single, untagged
vlan to operate across a link for compatability reasons, and calls
it the 'default' VLAN.  There is no requirement that it be VLAN 1.
That is, you could set the default vlan to be 10 on both sides,
and tag all the rest (including 1).  You could also set vlan 1 on
one side, and vlan 10 on the other, and they would be bridged
together.  Cisco devices warn when you do this (via CDP, it must
be enabled).

Convention seems to be that vlan 1 is the 'default vlan' on almost
all devices.

Having better notes in a man page would be good.

-- 
Leo Bicknell - [EMAIL PROTECTED]
Systems Engineer - Internetworking Engineer - CCIE 3440
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org

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

Question about VLAN dot1q tagging in FreeBSD

[Ulf Zimmermann]

Got a question for the people who worked on the support. All my
experience is under 4.3-Release/-Stable/4.4-RC3. A while back
when I wanted to use dot1q tagging, it seems to work fine with
the expection that I wasn't able to get VLAN 1 (default VLAN) to
work.

Last night I setup dot1q tagging again on another machine and had
the same problem. Looking into packets sent down the trunk, I saw
that VLAN 1 wasn't tagged (I assume the dot1q spec tells so that
VLAN 1 packets aren't tagged, while other VLANs are). If this is
right, I think we should mention this in the man page. Here is a
copy of the current man page of ifconfig in regards to VLAN:

 vlan vlan_tag
 If the interface is a vlan pseudo interface, set the vlan tag
 value to vlan_tag.  This value is a 16-bit number which is used
 to create an 802.1Q vlan header for packets sent from the vlan
 interface.  Note that vlan and vlandev must both be set at the
 same time.

 vlandev iface
 If the interface is a vlan pseudo device, associate physical
 interface iface with it.  Packets transmitted through the vlan
 interface will be diverted to the specified physical interface
 iface with 802.1Q vlan encapsulation.  Packets with 802.1Q encap-
 sulation received by the parent interface with the correct vlan
 tag will be diverted to the associated vlan pseudo-interface.
 The vlan interface is assigned a copy of the parent interface's
 flags and the parent's ethernet address.  The vlandev and vlan
 must both be set at the same time.  If the vlan interface already
 has a physical interface associated with it, this command will
 fail.  To change the association to another physical interface,
 the existing association must be cleared first.

 Note: if the link0 flag is set on the vlan interface, the vlan
 pseudo interface's behavior changes: the link0 tells the vlan
 interface that the parent interface supports insertion and
 extraction of vlan tags on its own (usually in firmware) and that
 it should pass packets to and from the parent unaltered.

 -vlandev iface
 If the driver is a vlan pseudo device, disassociate the physical
 interface iface from it.  This breaks the link between the vlan
 interface and its parent, clears its vlan tag, flags and its link
 address and shuts the interface down.

My current config in the case I setup last night looks like this from /etc/rc.conf:

network_interfaces="fxp0 vlan2 lo0"
ifconfig_fxp0="inet 192.168.0.250 netmask 255.255.255.0 media 100basetx mediaopt 
full-duplex"
ifconfig_vlan2="inet 64.81.63.130 netmask 255.255.255.224 vlan 2 vlandev fxp0"

192.168.0.250 is my private LAN which is VLAN 1 on my switches. VLAN 2 and 3
are my external networks (DSL/Cable Modem).

My suggestion is to add to ifconfig man page something like this under "vlan vlan_tag":

 Note: VLAN 1 is not tagged and should be put directly on the physical
 interface.

-- 
Regards, Ulf.

-
Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204

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

Re: signal handling descrpancy (FreeBSD oaf fix/Evolution)

[David Malone]

On Sun, Sep 02, 2001 at 09:55:03AM -0700, David O'Brien wrote:
> The PIM Evolution, http://www.ximian.com/products/ximian_evolution/,
> does not run on FreeBSD.  The authors have made a change so that it will.
> However, we would like to know if FreeBSD is the odd-man-out, or if the
> authors were lucky Evolution ran on Solaris and Linux.

I think this is the change which we had a patch for recently.  It
was committed to -current and -stable recently. Unfortunately there
was a small problem with the implimentation and had to be backed
out. I think either Matt or Ian or both had fixes for the problems,
but they haven't been recommitted yet.

David.

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

Re: Should URL's be pervasive.

[Mattias Pantzare]

> > NAME
> >  amd - automatically mount file systems
> > ...
> > DESCRIPTION
> >  Amd is a daemon that automatically mounts filesystems whenever a file or
> >  directory within that filesystem is accessed.  Filesystems are automati-
> >  cally unmounted when they appear to be quiescent.
> 
> Ahh, but that assumes that your AMD configuration has all systems and mount
> points enumerated in it.  Let me see - I think that 30gig drive may be big
> enough for that file :-)

No. Set amd_enable to YES in /etc/rc.conf and the default configuration will 
let you do a cd /net/nfs_servername.someplace to view all NFS exported 
filesystems on nfs_servername.someplace.



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

Re: Tagged Command Queuing support for IC-35L0?0 ?

[Jason Andresen]

Niek Bergboer wrote:
> 
> Hi,
> 
> I posted this message on -questions, and since I got no reply I've
> assumed that it's technical enough to post here on -hackers.
> 
> Since FBSD 4.3-RELEASE, tagged command queuing is supported for IBM
> DTLA and DPTA IDE drives. However, the newer "Deskstar GXP" drives
> also support TCQ according to IBM's website?
> 
> Can these newer drives, based on the IC-35L0?0-chipset, also be used
> with TCQ enabled in FBSD? (? is 2, 4 or 6 depending on whether the
> drive has 20, 40 or 60 GB capacity).

I think so:
ad0: 58644MB  [119150/16/63] at ata0-master tagged
UDMA33

I had to manually add "IC35L060AVER07-0" to ata-disk.c (around line 832)
to get FreeBSD to use it though.  

...
ad_tagsupported(struct ad_softc *adp)
{
const char *drives[] = {"IBM-DPTA", "IBM-DTLA", "IC35L060AVER07-0",
NULL};
...

This was a month or so though, so someone might have done the right
thing
and figured out how to parse those new IBM product strings to determine
if the drive supports CTQ or not. 

-- 
  \  |_ _|__ __|_ \ __| Jason Andresen[EMAIL PROTECTED]
 |\/ |  ||/ _|  Network and Distributed Systems Engineer
_|  _|___|  _| _|_\___| Office: 703-883-7755


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

Re: What is VT_TFS?

[Julian Elischer]

On Tue, 4 Sep 2001, Poul-Henning Kamp wrote:

> 
> Which reminds me, Adrian still oves us his story about ref :-)
Yeah, the REAL one...



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

Re: Junior Kernel Hacker task: improve vnode->v_tag

[Maxim Sobolev]

> 
> 
> apart from the numerical value, yes, looks good.

Ok, please find the final patch attached. Dare I say that it looks really
ugly?

I'm looking forward for your comments.

-Maxim

> 
> Poul-Henning
> 
> In message <[EMAIL PROTECTED]>, Maxim Sobolev writes:
> >
> >--%--multipart-mixed-boundary-1.97537.999617732--%
> >Content-Type: text/plain; charset=us-ascii
> >Content-Transfer-Encoding: 7bit
> >
> >> In message <[EMAIL PROTECTED]>, Maxim Sobolev writes:
> >> >> 
> >> >> In message <[EMAIL PROTECTED]>, Brent Verner writes:
> >> >> >
> >> >> >I've done a /cursory/ look over how this v_tag is used.  I'm not sure
> >> >> >this is a simple/clean as you propose, since this is used in the 
> >> >> >IS_LOCKING_VFS macro, as well as in union_subr.c...
> >> >> 
> >> > Well, that is just too bad, because IS_LOCKING_VFS is wrong then.
> >> >> 
> >> >> The places which inspect v_tag will have to be changed to use
> >> >> strcmp() then...
> >> >
> >> >I think that we can add a new vnode flag, say VCANLOCK, so that each
> >> >particular VFS can set it if it supports locking, which should allow
> >> >to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can
> >> >produce a patch if it sounds reasonably.
> >> 
> >> Yeah, I think that makes a lot of sense.
> >
> >See attached. Please let me know if it is OK for you.
> >
> >-Maxim
> >
> >--%--multipart-mixed-boundary-1.97537.999617732--%
> >Content-Type: text/plain; charset=us-ascii
> >Content-Transfer-Encoding: 7bit
> >Content-Description: ASCII C program text
> >Content-Disposition: attachment; filename="p"
> >
> >Index: isofs/cd9660/cd9660_vfsops.c
> >===
> >RCS file: /home/ncvs/src/sys/isofs/cd9660/cd9660_vfsops.c,v
> >retrieving revision 1.91
> >diff -d -u -r1.91 cd9660_vfsops.c
> >--- isofs/cd9660/cd9660_vfsops.c 2001/05/16 18:04:30 1.91
> >+++ isofs/cd9660/cd9660_vfsops.c 2001/09/04 15:20:46
> >@@ -697,6 +697,7 @@
> > }
> > MALLOC(ip, struct iso_node *, sizeof(struct iso_node), M_ISOFSNODE,
> > M_WAITOK | M_ZERO);
> >+vp->v_flag |= VLOCKABLE;
> > lockinit(&vp->v_lock, PINOD, "isonode", 0, 0);
> > /*
> >  * ISOFS uses stdlock and can share lock structure
> >Index: ufs/ffs/ffs_vfsops.c
> >===
> >RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v
> >retrieving revision 1.157
> >diff -d -u -r1.157 ffs_vfsops.c
> >--- ufs/ffs/ffs_vfsops.c 2001/06/28 22:21:27 1.157
> >+++ ufs/ffs/ffs_vfsops.c 2001/09/04 15:21:25
> >@@ -1172,6 +1172,7 @@
> > return (error);
> > }
> > bzero((caddr_t)ip, sizeof(struct inode));
> >+vp->v_flag |= VLOCKABLE;
> > /*
> >  * FFS supports lock sharing in the stack of vnodes
> >  */
> >Index: ufs/ifs/ifs_vfsops.c
> >===
> >RCS file: /home/ncvs/src/sys/ufs/ifs/ifs_vfsops.c,v
> >retrieving revision 1.6
> >diff -d -u -r1.6 ifs_vfsops.c
> >--- ufs/ifs/ifs_vfsops.c 2001/04/25 07:07:51 1.6
> >+++ ufs/ifs/ifs_vfsops.c 2001/09/04 15:21:25
> >@@ -217,6 +217,7 @@
> > return (error);
> > }
> > bzero((caddr_t)ip, sizeof(struct inode));
> >+vp->v_flag |= VLOCKABLE;
> > /*
> >  * IFS supports lock sharing in the stack of vnodes
> >  */
> >Index: nfs/nfs_node.c
> >===
> >RCS file: /home/ncvs/src/sys/nfs/nfs_node.c,v
> >retrieving revision 1.49
> >diff -d -u -r1.49 nfs_node.c
> >--- nfs/nfs_node.c   2001/05/01 08:13:14 1.49
> >+++ nfs/nfs_node.c   2001/09/04 15:21:25
> >@@ -232,6 +232,7 @@
> > }
> > vp = nvp;
> > bzero((caddr_t)np, sizeof *np);
> >+vp->v_flag |= VLOCKABLE;
> > vp->v_data = np;
> > np->n_vnode = vp;
> > /*
> >Index: sys/vnode.h
> >===
> >RCS file: /home/ncvs/src/sys/sys/vnode.h,v
> >retrieving revision 1.154
> >diff -d -u -r1.154 vnode.h
> >--- sys/vnode.h  2001/08/27 06:09:55 1.154
> >+++ sys/vnode.h  2001/09/04 15:21:25
> >@@ -175,6 +175,7 @@
> > /* open for business0x10 */
> > #define VONWORKLST  0x20 /* On syncer work-list */
> > #define VMOUNT  0x40 /* Mount in progress */
> >+#define VLOCKABLE   0x60 /* vnode supports locking */
> > 
> > /*
> >  * Vnode attributes.  A field value of VNOVAL represents a field whose value
> >@@ -433,12 +434,7 @@
> > /*
> >  * [dfr] Kludge until I get around to fixing all the vfs locking.
> >  */
> >-#define IS_LOCKING_VFS(vp)  ((vp)->v_tag == VT_UFS  \
> >- || (vp)->v_tag == VT_NFS   \
> >- || (vp)->v_tag == VT_LFS   \
> >- || (vp)->v_tag == VT_ISOFS \
> >- || (vp)->v_tag == VT_MSDOSFS   

Tagged Command Queuing support for IC-35L0?0 ?

[Niek Bergboer]

Hi,

I posted this message on -questions, and since I got no reply I've
assumed that it's technical enough to post here on -hackers.

Since FBSD 4.3-RELEASE, tagged command queuing is supported for IBM
DTLA and DPTA IDE drives. However, the newer "Deskstar GXP" drives
also support TCQ according to IBM's website?

Can these newer drives, based on the IC-35L0?0-chipset, also be used
with TCQ enabled in FBSD? (? is 2, 4 or 6 depending on whether the
drive has 20, 40 or 60 GB capacity).

Thanks in advance,

Niek Bergboer


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

Re: What is VT_TFS?

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Nate Williams writes:

>> TRW supported a lot of the early
>> 386BSD/FreeBSD effort, back before Walnut Creek CDROM threw
>> in and had us change the version number from 0.1 to 1.0 to
>> make it a bit easier to sell.
>
>*Huh*  That's revisionist history if I've ever heard it.  We did a 1.0
>release for FreeBSD because we wanted to differentiate ourselves from
>386BSD (lot of bad blood there with the Jolitz's) and NetBSD (which had
>a 0.8 release at that time).

Nate,

You're replying to Terry for christs sake!  What did you expect if not
revisionist $anything ?

Which reminds me, Adrian still oves us his story about ref :-)


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

Re: What is VT_TFS?

[Nate Williams]

> > What is the file system that uses VT_TFS in vnode.h? Is it still available
> > on FreeBSD?  Thanks.
> 
> Julian added it for TRW Financial Services; the first public
> reference machine for 386BSD (which later became FreeBSD and
> NetBSD) was ref.tfs.com.

So far so good.  ref died an ugly horrible death, although I think I
still have lying around a 4mm backup tape of what was left of it.

> TRW supported a lot of the early
> 386BSD/FreeBSD effort, back before Walnut Creek CDROM threw
> in and had us change the version number from 0.1 to 1.0 to
> make it a bit easier to sell.

*Huh*  That's revisionist history if I've ever heard it.  We did a 1.0
release for FreeBSD because we wanted to differentiate ourselves from
386BSD (lot of bad blood there with the Jolitz's) and NetBSD (which had
a 0.8 release at that time).




Nate

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

Re: Junior Kernel Hacker task: improve vnode->v_tag

[Bruce Evans]

On Tue, 4 Sep 2001, Maxim Sobolev wrote:

> > [neither Maxim Sobolev nor Brent Verner wrote]
> > In message <[EMAIL PROTECTED]>, Brent Verner writes:
> > >#include 
> > >
> > >I've done a /cursory/ look over how this v_tag is used.  I'm not sure
> > >this is a simple/clean as you propose, since this is used in the
> > >IS_LOCKING_VFS macro, as well as in union_subr.c...
> >
> > Well, that is just too bad, because IS_LOCKING_VFS is wrong then.
> >
> > The places which inspect v_tag will have to be changed to use
> > strcmp() then...
>
> I think that we can add a new vnode flag, say VCANLOCK, so that each
> particular VFS can set it if it supports locking, which should allow
> to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can
> produce a patch if it sounds reasonably.

Since IS_LOCKING_VFS() is a temporary kludge, the correct fix is to remove
it (after fixing whatever it was for), not to add more cruft.

Bruce


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

Re: Junior Kernel Hacker task: improve vnode->v_tag

[Boris Popov]

On Tue, 4 Sep 2001, Maxim Sobolev wrote:

> > The places which inspect v_tag will have to be changed to use
> > strcmp() then...
> 
> I think that we can add a new vnode flag, say VCANLOCK, so that each
> particular VFS can set it if it supports locking, which should allow
> to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can
> produce a patch if it sounds reasonably.

I'm not sure if this a right thing to do. Under SMPng each
filesystem is ought to implement correct vnode locking, i.e. vop_nolock()
and friends shouldn't exist.

-- 
Boris Popov
http://rbp.euro.ru


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

REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions

[Robert Watson]

It's that time again!  I'm in the process of preparing the August, 2001
FreeBSD monthly status report, and as such am interested in seeing
submissions in much the same style as previous months.  Generally, this
means about one paragraph of text per project describing events that have
occured since the last status report (or two paragraphs for new projects,
so as to introduce them).  Large projects can be broken down into multiple
sub-projects with seperate reports reports.  If multiple developers are
working on the same project, they should coordinate so as to submit only
one report (or split it up into parts as appropriate along logical
boundaries).

Reports should relate to the FreeBSD Project, but are not limited to
on-going software development: documentation, public relations,
management, application developer relations, technology transfer, etc, are
all relevant.

Please submit reports in the following format: 

Project: (name here -- required field)
URL: (URL, if any, here -- omit field if none)
Contact: (name and e-mail address of one or more contact points --
 required field)

  One paragraph on the topic of project status since the last report,
  indented two spaces, and wrapped at column 78.  Plain text only,
  please.

Please send submissions to:

  [EMAIL PROTECTED]

The deadline for submissions is September 7, 2001, at 3:00pm EST.  The
report will be released soon thereafter.

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]  NAI Labs, Safeport Network Services



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

4.4-RC3 scontrib and other files problem ?

[Ulf Zimmermann]

Tried to install complete source tree via sysinstall and it
always fails on scontrib with unexpected EOF. And it seems
several of the chunks are not the usual 240640 bytes in size.
Checked several of the FTP servers:

-r--r--r--  1 1006  1006   231335 Sep  2 04:23 sbin.ab
-r--r--r--  1 1006  1006 3763 Sep  1 18:55 scontrib.cq
-r--r--r--  1 1006  100663151 Sep  1 18:55 scontrib.cu
-r--r--r--  1 1006  1006 7233 Sep  1 18:55 scontrib.cz
-r--r--r--  1 1006  1006  2145984 Sep  1 18:55 scontrib.eh
-r--r--r--  1 1006  100666801 Sep  1 18:55 scontrib.en
-r--r--r--  1 1006  1006  1096775 Sep  1 18:55 scontrib.ex
-r--r--r--  1 1006  1006  6778448 Sep  1 18:55 sgames.ag  
-r--r--r--  1 1006  1006 7834 Sep  1 18:55 slib.bb

All the ones which are shorter then 240640 bytes are no the last
file in their sequences.

-- 
Regards, Ulf.

-
Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204

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

Re: Junior Kernel Hacker task: improve vnode->v_tag

[Maxim Sobolev]

> 
> Hi Maxim,
> 
> Perhaps you meant:
> diff -d -u -r1.154 vnode.h
> --- sys/vnode.h 2001/08/27 06:09:55 1.154
> +++ sys/vnode.h 2001/09/04 15:21:25
> @@ -175,6 +175,7 @@
>  /* open for business   0x10 */
>  #defineVONWORKLST  0x20 /* On syncer work-list */
>  #defineVMOUNT  0x40 /* Mount in progress */
> +#define VLOCKABLE  0x60 /* vnode supports locking */
> ...should be
> +#define VLOCKABLE  0x80 /* vnode supports locking */

Indeed. Thank you for pointing out!

-Maxim

> 
> 
> 
> Maxim Sobolev wrote:
> 
> > > In message <[EMAIL PROTECTED]>, Maxim Sobolev writes:
> > > >>
> > > >> In message <[EMAIL PROTECTED]>, Brent Verner writes:
> > > >> >
> > > >> >I've done a /cursory/ look over how this v_tag is used.  I'm not sure
> > > >> >this is a simple/clean as you propose, since this is used in the
> > > >> >IS_LOCKING_VFS macro, as well as in union_subr.c...
> > > >>
> > > > Well, that is just too bad, because IS_LOCKING_VFS is wrong then.
> > > >>
> > > >> The places which inspect v_tag will have to be changed to use
> > > >> strcmp() then...
> > > >
> > > >I think that we can add a new vnode flag, say VCANLOCK, so that each
> > > >particular VFS can set it if it supports locking, which should allow
> > > >to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can
> > > >produce a patch if it sounds reasonably.
> > >
> > > Yeah, I think that makes a lot of sense.
> >
> > See attached. Please let me know if it is OK for you.
> >
> > -Maxim
> >
> >   --
> >Name: p
> >p   Type: Plain Text (text/plain)
> >Encoding: 7bit
> > Description: ASCII C program text
> 
> --
>  * *   Konstantin Chuguev   Francis House
>   *  * Application Engineer 112 Hills Road
> *  Tel: +44 1223 302992 Cambridge CB2 1PQ
> D  A  N  T  E  WWW: http://www.dante.netUnited Kingdom
> 
> 
> 
> 


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

Re: Should URL's be pervasive.

[Joseph Mallett]

What strikes me in this thread is that a lot of people are stupid and lazy 
and want FreeBSD's kernel (or libc) to do stupid things with URLs the same 
way you can throw a URL anywhere in Windows and have it mean something.

Here's some news for you: It shouldn't, and probably won't, happen.

If you really want something that insane and obscene and that much of a 
bastardisation of EVERYTHING networking-related, check in with the BASH 
people and do it on the shell level.

If you're really lazy and want to be able to do:
telnet smtp://localhost
I suggest you look into this relatively new invention called 
'/etc/services' and read some manual pages. You'll find you can do 
something quite similar, and much saner.

/joseph

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

Re: Junior Kernel Hacker task: improve vnode->v_tag

[Poul-Henning Kamp]

apart from the numerical value, yes, looks good.

Poul-Henning

In message <[EMAIL PROTECTED]>, Maxim Sobolev writes:
>
>--%--multipart-mixed-boundary-1.97537.999617732--%
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>> In message <[EMAIL PROTECTED]>, Maxim Sobolev writes:
>> >> 
>> >> In message <[EMAIL PROTECTED]>, Brent Verner writes:
>> >> >
>> >> >I've done a /cursory/ look over how this v_tag is used.  I'm not sure
>> >> >this is a simple/clean as you propose, since this is used in the 
>> >> >IS_LOCKING_VFS macro, as well as in union_subr.c...
>> >> 
>> > Well, that is just too bad, because IS_LOCKING_VFS is wrong then.
>> >> 
>> >> The places which inspect v_tag will have to be changed to use
>> >> strcmp() then...
>> >
>> >I think that we can add a new vnode flag, say VCANLOCK, so that each
>> >particular VFS can set it if it supports locking, which should allow
>> >to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can
>> >produce a patch if it sounds reasonably.
>> 
>> Yeah, I think that makes a lot of sense.
>
>See attached. Please let me know if it is OK for you.
>
>-Maxim
>
>--%--multipart-mixed-boundary-1.97537.999617732--%
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>Content-Description: ASCII C program text
>Content-Disposition: attachment; filename="p"
>
>Index: isofs/cd9660/cd9660_vfsops.c
>===
>RCS file: /home/ncvs/src/sys/isofs/cd9660/cd9660_vfsops.c,v
>retrieving revision 1.91
>diff -d -u -r1.91 cd9660_vfsops.c
>--- isofs/cd9660/cd9660_vfsops.c   2001/05/16 18:04:30 1.91
>+++ isofs/cd9660/cd9660_vfsops.c   2001/09/04 15:20:46
>@@ -697,6 +697,7 @@
>   }
>   MALLOC(ip, struct iso_node *, sizeof(struct iso_node), M_ISOFSNODE,
>   M_WAITOK | M_ZERO);
>+  vp->v_flag |= VLOCKABLE;
>   lockinit(&vp->v_lock, PINOD, "isonode", 0, 0);
>   /*
>* ISOFS uses stdlock and can share lock structure
>Index: ufs/ffs/ffs_vfsops.c
>===
>RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v
>retrieving revision 1.157
>diff -d -u -r1.157 ffs_vfsops.c
>--- ufs/ffs/ffs_vfsops.c   2001/06/28 22:21:27 1.157
>+++ ufs/ffs/ffs_vfsops.c   2001/09/04 15:21:25
>@@ -1172,6 +1172,7 @@
>   return (error);
>   }
>   bzero((caddr_t)ip, sizeof(struct inode));
>+  vp->v_flag |= VLOCKABLE;
>   /*
>* FFS supports lock sharing in the stack of vnodes
>*/
>Index: ufs/ifs/ifs_vfsops.c
>===
>RCS file: /home/ncvs/src/sys/ufs/ifs/ifs_vfsops.c,v
>retrieving revision 1.6
>diff -d -u -r1.6 ifs_vfsops.c
>--- ufs/ifs/ifs_vfsops.c   2001/04/25 07:07:51 1.6
>+++ ufs/ifs/ifs_vfsops.c   2001/09/04 15:21:25
>@@ -217,6 +217,7 @@
>   return (error);
>   }
>   bzero((caddr_t)ip, sizeof(struct inode));
>+  vp->v_flag |= VLOCKABLE;
>   /*
>* IFS supports lock sharing in the stack of vnodes
>*/
>Index: nfs/nfs_node.c
>===
>RCS file: /home/ncvs/src/sys/nfs/nfs_node.c,v
>retrieving revision 1.49
>diff -d -u -r1.49 nfs_node.c
>--- nfs/nfs_node.c 2001/05/01 08:13:14 1.49
>+++ nfs/nfs_node.c 2001/09/04 15:21:25
>@@ -232,6 +232,7 @@
>   }
>   vp = nvp;
>   bzero((caddr_t)np, sizeof *np);
>+  vp->v_flag |= VLOCKABLE;
>   vp->v_data = np;
>   np->n_vnode = vp;
>   /*
>Index: sys/vnode.h
>===
>RCS file: /home/ncvs/src/sys/sys/vnode.h,v
>retrieving revision 1.154
>diff -d -u -r1.154 vnode.h
>--- sys/vnode.h2001/08/27 06:09:55 1.154
>+++ sys/vnode.h2001/09/04 15:21:25
>@@ -175,6 +175,7 @@
> /* open for business  0x10 */
> #define   VONWORKLST  0x20 /* On syncer work-list */
> #define   VMOUNT  0x40 /* Mount in progress */
>+#define VLOCKABLE 0x60 /* vnode supports locking */
> 
> /*
>  * Vnode attributes.  A field value of VNOVAL represents a field whose value
>@@ -433,12 +434,7 @@
> /*
>  * [dfr] Kludge until I get around to fixing all the vfs locking.
>  */
>-#define IS_LOCKING_VFS(vp)((vp)->v_tag == VT_UFS  \
>-   || (vp)->v_tag == VT_NFS   \
>-   || (vp)->v_tag == VT_LFS   \
>-   || (vp)->v_tag == VT_ISOFS \
>-   || (vp)->v_tag == VT_MSDOSFS   \
>-   || (vp)->v_tag == VT_DEVFS)
>+#define IS_LOCKING_VFS(vp)((vp)->v_flag & VLOCKABLE)
> 
> #define ASSERT_VOP_LOCKED(vp, str)\
> do {  \
>Index: fs/devfs/devfs_v

Re: Junior Kernel Hacker task: improve vnode->v_tag

[Konstantin Chuguev]

Hi Maxim,

Perhaps you meant:
diff -d -u -r1.154 vnode.h
--- sys/vnode.h 2001/08/27 06:09:55 1.154
+++ sys/vnode.h 2001/09/04 15:21:25
@@ -175,6 +175,7 @@
 /* open for business   0x10 */
 #defineVONWORKLST  0x20 /* On syncer work-list */
 #defineVMOUNT  0x40 /* Mount in progress */
+#define VLOCKABLE  0x60 /* vnode supports locking */
...should be
+#define VLOCKABLE  0x80 /* vnode supports locking */

?

Regards,
Konstantin.



Maxim Sobolev wrote:

> > In message <[EMAIL PROTECTED]>, Maxim Sobolev writes:
> > >>
> > >> In message <[EMAIL PROTECTED]>, Brent Verner writes:
> > >> >
> > >> >I've done a /cursory/ look over how this v_tag is used.  I'm not sure
> > >> >this is a simple/clean as you propose, since this is used in the
> > >> >IS_LOCKING_VFS macro, as well as in union_subr.c...
> > >>
> > > Well, that is just too bad, because IS_LOCKING_VFS is wrong then.
> > >>
> > >> The places which inspect v_tag will have to be changed to use
> > >> strcmp() then...
> > >
> > >I think that we can add a new vnode flag, say VCANLOCK, so that each
> > >particular VFS can set it if it supports locking, which should allow
> > >to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can
> > >produce a patch if it sounds reasonably.
> >
> > Yeah, I think that makes a lot of sense.
>
> See attached. Please let me know if it is OK for you.
>
> -Maxim
>
>   --
>Name: p
>p   Type: Plain Text (text/plain)
>Encoding: 7bit
> Description: ASCII C program text

--
 * *   Konstantin Chuguev   Francis House
  *  * Application Engineer 112 Hills Road
*  Tel: +44 1223 302992 Cambridge CB2 1PQ
D  A  N  T  E  WWW: http://www.dante.netUnited Kingdom




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

Re: Junior Kernel Hacker task: improve vnode->v_tag

[Maxim Sobolev]

> In message <[EMAIL PROTECTED]>, Maxim Sobolev writes:
> >> 
> >> In message <[EMAIL PROTECTED]>, Brent Verner writes:
> >> >
> >> >I've done a /cursory/ look over how this v_tag is used.  I'm not sure
> >> >this is a simple/clean as you propose, since this is used in the 
> >> >IS_LOCKING_VFS macro, as well as in union_subr.c...
> >> 
> > Well, that is just too bad, because IS_LOCKING_VFS is wrong then.
> >> 
> >> The places which inspect v_tag will have to be changed to use
> >> strcmp() then...
> >
> >I think that we can add a new vnode flag, say VCANLOCK, so that each
> >particular VFS can set it if it supports locking, which should allow
> >to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can
> >produce a patch if it sounds reasonably.
> 
> Yeah, I think that makes a lot of sense.

See attached. Please let me know if it is OK for you.

-Maxim


Index: isofs/cd9660/cd9660_vfsops.c
===
RCS file: /home/ncvs/src/sys/isofs/cd9660/cd9660_vfsops.c,v
retrieving revision 1.91
diff -d -u -r1.91 cd9660_vfsops.c
--- isofs/cd9660/cd9660_vfsops.c2001/05/16 18:04:30 1.91
+++ isofs/cd9660/cd9660_vfsops.c2001/09/04 15:20:46
@@ -697,6 +697,7 @@
}
MALLOC(ip, struct iso_node *, sizeof(struct iso_node), M_ISOFSNODE,
M_WAITOK | M_ZERO);
+   vp->v_flag |= VLOCKABLE;
lockinit(&vp->v_lock, PINOD, "isonode", 0, 0);
/*
 * ISOFS uses stdlock and can share lock structure
Index: ufs/ffs/ffs_vfsops.c
===
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.157
diff -d -u -r1.157 ffs_vfsops.c
--- ufs/ffs/ffs_vfsops.c2001/06/28 22:21:27 1.157
+++ ufs/ffs/ffs_vfsops.c2001/09/04 15:21:25
@@ -1172,6 +1172,7 @@
return (error);
}
bzero((caddr_t)ip, sizeof(struct inode));
+   vp->v_flag |= VLOCKABLE;
/*
 * FFS supports lock sharing in the stack of vnodes
 */
Index: ufs/ifs/ifs_vfsops.c
===
RCS file: /home/ncvs/src/sys/ufs/ifs/ifs_vfsops.c,v
retrieving revision 1.6
diff -d -u -r1.6 ifs_vfsops.c
--- ufs/ifs/ifs_vfsops.c2001/04/25 07:07:51 1.6
+++ ufs/ifs/ifs_vfsops.c2001/09/04 15:21:25
@@ -217,6 +217,7 @@
return (error);
}
bzero((caddr_t)ip, sizeof(struct inode));
+   vp->v_flag |= VLOCKABLE;
/*
 * IFS supports lock sharing in the stack of vnodes
 */
Index: nfs/nfs_node.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_node.c,v
retrieving revision 1.49
diff -d -u -r1.49 nfs_node.c
--- nfs/nfs_node.c  2001/05/01 08:13:14 1.49
+++ nfs/nfs_node.c  2001/09/04 15:21:25
@@ -232,6 +232,7 @@
}
vp = nvp;
bzero((caddr_t)np, sizeof *np);
+   vp->v_flag |= VLOCKABLE;
vp->v_data = np;
np->n_vnode = vp;
/*
Index: sys/vnode.h
===
RCS file: /home/ncvs/src/sys/sys/vnode.h,v
retrieving revision 1.154
diff -d -u -r1.154 vnode.h
--- sys/vnode.h 2001/08/27 06:09:55 1.154
+++ sys/vnode.h 2001/09/04 15:21:25
@@ -175,6 +175,7 @@
 /* open for business   0x10 */
 #defineVONWORKLST  0x20 /* On syncer work-list */
 #defineVMOUNT  0x40 /* Mount in progress */
+#define VLOCKABLE  0x60 /* vnode supports locking */
 
 /*
  * Vnode attributes.  A field value of VNOVAL represents a field whose value
@@ -433,12 +434,7 @@
 /*
  * [dfr] Kludge until I get around to fixing all the vfs locking.
  */
-#define IS_LOCKING_VFS(vp) ((vp)->v_tag == VT_UFS  \
-|| (vp)->v_tag == VT_NFS   \
-|| (vp)->v_tag == VT_LFS   \
-|| (vp)->v_tag == VT_ISOFS \
-|| (vp)->v_tag == VT_MSDOSFS   \
-|| (vp)->v_tag == VT_DEVFS)
+#define IS_LOCKING_VFS(vp) ((vp)->v_flag & VLOCKABLE)
 
 #define ASSERT_VOP_LOCKED(vp, str) \
 do {   \
Index: fs/devfs/devfs_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/devfs/devfs_vnops.c,v
retrieving revision 1.27
diff -d -u -r1.27 devfs_vnops.c
--- fs/devfs/devfs_vnops.c  2001/08/14 06:42:32 1.27
+++ fs/devfs/devfs_vnops.c  2001/09/04 15:21:25
@@ -151,6 +151,7 @@
} else {
vp->v_type = VBAD;
}
+   vp->v_flag |= VLOCKABLE;
vp->v_data = de;
de->de_vnode = vp;
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p);
Index: fs/msdosfs/msdosfs_denode.c
=

Re: Should URL's be pervasive.

[Charlie Root]

> All of this started with the quest for URIs being useable everywhere.

It's a stupid quest, for reasons others have pointed out.

> > When this isn't possible or
> > reasonable, it's not only difficult but *wrong* to abstract.
>
> I never said this was trivial.  We (which includes me) tried to start
> such a project at Amiga (Commodore) - It was well before HTTP was so
> popular.  The goal was to hide the specifics and provide a single operation.
> FTP support was via a local cache while the file was open and if you did
> a write, it would write back the file at close time.

See above. There's a reason AFS hasn't replaced NFS.

> I was not asking for a magic bullet.  (Well, not this time :-)
> I was asking that the OS support reading and/or writing of data (whatever
> that may be) to a file/filehandle that was created via a standard
> system call.

Pipes, named or otherwise.

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

KLD subsystem improvement

[Eugene L. Vorokov]

Hello,

I'm going to implement a small improvement to a KLD system. I want linker
file not to be loaded at all when all modules inside it fail to load for
some reasons. I think that would be logical behaviour. Does anyone think
that such change would break something ?

Regards,
Eugene


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

Re: Should URL's be pervasive.

[Michael Sinz]

Charlie Root wrote:
> 
> > What I was trying to say is that there is no reason that I should care
> > if the file is local or not.
> 
> You do need to know if the file is local or not. You need to know
> for security. You need to know because files behave differently on
> different machines. You need to know because file structures don't
> map from one machine to another. You need to know because
> differing protocols allow you do to very different things to
> files. You need to know because performance varies dramatically
> depending on where the file is located.

Ok - so my server here has files that various platforms access via NFS.
The fact that everything accesses the files via NFS does not reduce or
change the fact that the endian nature of the platform or the word size
of the platform need to be either understood or that the file format be
strictly structured so as to no matter.

And if you think that each application needs to know about the different
semantics of the file storage system, why is NFS just like FFS just like UFS
just like FAT16 just like...

Each has different limits and behaviors.  NFS is very stateless.  Local
file systems are much more stateful.  FAT has file name restrictions (pre-VFAT
it was 8.3 with upper case only, for example)  ISO9660 has depth limits and
version numbers, VMS has version numbers and different character exclusions,
etc.

Some of these limits are annoying and, in some cases, incompatible with
the work you may wish to do.  However, most of these are limits that are
also limits on other file systems (albeit different - 32 character names
or 255 character names, for example, but still a name length limit)

Performance differences are vast, even with local files.  Have you written
to a floppy lately.  Almost all my network connected disks are *much* faster.
How about that slow MO drive?  Or that ultra-fast SCSI RAID pack?

At some point the performance issues are just "if you use X it will not
perform like Y" and not a "this program can't use X because we feel it
does not perform well enough and thus we did not code for it."

(cp, mv, etc, all work with floppy disks and other slow media...)

> > Just as the OS support having multiple storage devices and media and the
> > software does not need to know if the file is on a SCSI or IDE disk or if
> > it is on DISK 2 partition 3 or DISK 5 partition 1, why should it know if
> > it is local or on the machine beside it or on the machine on the other side
> > of the world?
> 
> The OS support of multiple device types exists because it is
> possible and reasonable to abstract each of those device types
> into a single "virtual" type. When this isn't possible or
> reasonable, it's not only difficult but *wrong* to abstract. There
> are way too many things you can do with a local file that you
> can't do with a remote file to allow this abstraction.

I never said this was trivial.  We (which includes me) tried to start
such a project at Amiga (Commodore) - It was well before HTTP was so
popular.  The goal was to hide the specifics and provide a single operation.
FTP support was via a local cache while the file was open and if you did
a write, it would write back the file at close time.  This is due to
limits in the ftp protocol, but it did not change the behavior to the
application.  The fact that writes were not instant to the FTP server was
just one of the differences between it and other file systems.  NFS had
other limits.  Our own network filesystem had yet other design goals
and thus different limits/behaviors.

The hard part we faced was the fact that the computers were much less
powerful than today (slower/less RAM/ etc) and that Amiga(Commodore) was
not very focused on networking (or anything else other than loosing money :-)

> > Anyway, the point is that a file that I can access should be a file I
> > can access via VI or MORE or EMACS or GREP or any other tool without
> > having those tools each having FTP and HTTP and SSH support built in to
> > them.  The OS should handle it.
> 
> No it should not. It's not reasonable for the *operating system*
> to know about every damned protocol that someone decides would be
> a just peachy way to access a file. Hell, it's not even practical.

Not every protocol - or maybe every protocol supported by people who
make the protocol filters.  This is where external (to the kernel)
protocol filters fit in well.  But lets not go there (now).

All of this started with the quest for URIs being useable everywhere.
That is a nice starting point for an idea.  Now, if I gave you foobar://xx/yy
you might not know what to do with the foobar protocol from the URI.
That would be an error, much like but not exactly like, file not found.
(It would be unknown protocol as a subset of file not found, much like
when you use /var/lof/messages when you were going to use /var/log/messages)

> The idea of universal abstraction just does not work. If you think
> otherwise, I suggest you start coding a

Re: Should URL's be pervasive.

[Kenneth P. Stox]

On 04-Sep-01 Michael Sinz wrote:
> Sansonetti Laurent wrote:
>> 
>> > Anyway, the point is that a file that I can access should be a file I
>> > can access via VI or MORE or EMACS or GREP or any other tool without
>> > having those tools each having FTP and HTTP and SSH support built in to
>> > them.  The OS should handle it.
>> 
>> Yes, this should be nice.  There's a similar project for Linux here:
>> http://ftpfs.sourceforge.net/ (FTP only).
>> It would be amusing to port it into a KLD file.
> 
> Hmmm... Looks like a good first step

You may also wish to take a look at wwfs:



--
E-Mail: Kenneth P. Stox <[EMAIL PROTECTED]>
Date: 04-Sep-01
Time: 09:57:36
--

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

Re: Should URL's be pervasive.

[Michael Sinz]

Sansonetti Laurent wrote:
> 
> > Anyway, the point is that a file that I can access should be a file I
> > can access via VI or MORE or EMACS or GREP or any other tool without
> > having those tools each having FTP and HTTP and SSH support built in to
> > them.  The OS should handle it.
> 
> Yes, this should be nice.  There's a similar project for Linux here:
> http://ftpfs.sourceforge.net/ (FTP only).
> It would be amusing to port it into a KLD file.

Hmmm... Looks like a good first step

-- 
Michael Sinz  Worldgate Communications  [EMAIL PROTECTED]
A master's secrets are only as good as
the master's ability to explain them to others.

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

Re: Should URL's be pervasive.

[Charlie Root]

> What I was trying to say is that there is no reason that I should care
> if the file is local or not.

You do need to know if the file is local or not. You need to know
for security. You need to know because files behave differently on
different machines. You need to know because file structures don't
map from one machine to another. You need to know because
differing protocols allow you do to very different things to
files. You need to know because performance varies dramatically
depending on where the file is located.

> Just as the OS support having multiple storage devices and media and the
> software does not need to know if the file is on a SCSI or IDE disk or if
> it is on DISK 2 partition 3 or DISK 5 partition 1, why should it know if
> it is local or on the machine beside it or on the machine on the other side
> of the world?

The OS support of multiple device types exists because it is
possible and reasonable to abstract each of those device types
into a single "virtual" type. When this isn't possible or
reasonable, it's not only difficult but *wrong* to abstract. There
are way too many things you can do with a local file that you
can't do with a remote file to allow this abstraction.

> Anyway, the point is that a file that I can access should be a file I
> can access via VI or MORE or EMACS or GREP or any other tool without
> having those tools each having FTP and HTTP and SSH support built in to
> them.  The OS should handle it.

No it should not. It's not reasonable for the *operating system*
to know about every damned protocol that someone decides would be
a just peachy way to access a file. Hell, it's not even practical.

The idea of universal abstraction just does not work. If you think
otherwise, I suggest you start coding and stop bothering the rest
of us until you've made it work.

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

Re: Should URL's be pervasive.

[Sansonetti Laurent]

> Anyway, the point is that a file that I can access should be a file I
> can access via VI or MORE or EMACS or GREP or any other tool without
> having those tools each having FTP and HTTP and SSH support built in to
> them.  The OS should handle it.

Yes, this should be nice.  There's a similar project for Linux here:
http://ftpfs.sourceforge.net/ (FTP only).
It would be amusing to port it into a KLD file.

--



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

Re: Junior Kernel Hacker task: improve vnode->v_tag

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Maxim Sobolev writes:
>> 
>> In message <[EMAIL PROTECTED]>, Brent Verner writes:
>> >On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote:
>> >| 
>> >| Assignment:
>> >| 
>> >| The v_tag element in struct vnode is a debugging aid, but unfortunately
>> >| it is implemented in a way which means that adding a filesystem means
>> >| modifying the definition in .
>> >| 
>> >| Convert the v_tag to an "const char *" and have the filesystems put
>> >| their name in there instead.
>> >| 
>> >| The v_tag has been abused a few places, easily recognizable by the fact
>> >| that the kernel should never inspect the value of v_tag.
>> >| These places should be easily changeable to use the new representation.
>> >| Please mark them with a big fat "/*XXX: ABUSE OF v_tag */" comment.
>> >
>> >#include 
>> >
>> >I've done a /cursory/ look over how this v_tag is used.  I'm not sure
>> >this is a simple/clean as you propose, since this is used in the 
>> >IS_LOCKING_VFS macro, as well as in union_subr.c...
>> 
> Well, that is just too bad, because IS_LOCKING_VFS is wrong then.
>> 
>> The places which inspect v_tag will have to be changed to use
>> strcmp() then...
>
>I think that we can add a new vnode flag, say VCANLOCK, so that each
>particular VFS can set it if it supports locking, which should allow
>to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can
>produce a patch if it sounds reasonably.

Yeah, I think that makes a lot of sense.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

Re: Junior Kernel Hacker task: improve vnode->v_tag

[Maxim Sobolev]

> 
> In message <[EMAIL PROTECTED]>, Brent Verner writes:
> >On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote:
> >| 
> >| Assignment:
> >| 
> >| The v_tag element in struct vnode is a debugging aid, but unfortunately
> >| it is implemented in a way which means that adding a filesystem means
> >| modifying the definition in .
> >| 
> >| Convert the v_tag to an "const char *" and have the filesystems put
> >| their name in there instead.
> >| 
> >| The v_tag has been abused a few places, easily recognizable by the fact
> >| that the kernel should never inspect the value of v_tag.
> >| These places should be easily changeable to use the new representation.
> >| Please mark them with a big fat "/*XXX: ABUSE OF v_tag */" comment.
> >
> >#include 
> >
> >I've done a /cursory/ look over how this v_tag is used.  I'm not sure
> >this is a simple/clean as you propose, since this is used in the 
> >IS_LOCKING_VFS macro, as well as in union_subr.c...
> 
> Well, that is just too bad, because IS_LOCKING_VFS is wrong then.
> 
> The places which inspect v_tag will have to be changed to use
> strcmp() then...

I think that we can add a new vnode flag, say VCANLOCK, so that each
particular VFS can set it if it supports locking, which should allow
to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can
produce a patch if it sounds reasonably.

-Maxim


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

Re: gzipped crashdumps

[Michael Sinz]

John Polstra wrote:
> 
> In article <[EMAIL PROTECTED]>,
> Kris Kennaway  <[EMAIL PROTECTED]> wrote:
> >
> > Anyone else think this patch from NetBSD is worthwhile?
> 
> Yes yes yes yes yes!  That's 5 votes in favor of it already. :-)

Add in another 50 here (the number of machines here that produce
dumps in our test lab :-()

-- 
Michael Sinz  Worldgate Communications  [EMAIL PROTECTED]
A master's secrets are only as good as
the master's ability to explain them to others.

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

Re: FreeBSD and Athlon Processors

[Jason Andresen]

Terry Lambert wrote:
> 
> David O'Brien wrote:
> > > > Well, since it didn't, I might as well explain the problem here too.
> > > > There are at least two major problems with VIA chips:
> > >
> > > [data curruption on VIA KT133/133A systems by pushing PCI and memory bus]
> > >
> > > Are you sure about that?
> >
> > I am.  I was having data coruption in a terrable way when I added a 2nd
> > IDE UDA100 drive to a very plain MSI K7T Pro2-A 1.2GHz Athlon system.
> 
> Are you sure it's not just a CMD640 IDE controller?  They are
> known to have issues; Linux has a patch... FreeBSD used to, but
> I think it got yanked out, or was just turned off by default.

I didn't think anybody used the CMD640 anymore (not since early
Pentium days even).  Anyway sys/pci/ide_pci.c still has the
workaround for the CMD640, it's just not a kernel option
anymore because FreeBSD automagically detects and installs
the workaround now if you have one.  

-- 
  \  |_ _|__ __|_ \ __| Jason Andresen[EMAIL PROTECTED]
 |\/ |  ||/ _|  Network and Distributed Systems Engineer
_|  _|___|  _| _|_\___| Office: 703-883-7755


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

Re: Should URL's be pervasive.

[Michael Sinz]

Paul Chvostek wrote:
> 
> On Fri, Aug 31, 2001 at 02:15:09PM -0400, Michael Sinz wrote:
> >
> > I too have been hoping for (and building internal tools) that work
> > this way.  I really wish you could just do:
> >
> >   open("nfs://server.name.dom/directory/file.txt")
> 
> NAME
>  amd - automatically mount file systems
> ...
> DESCRIPTION
>  Amd is a daemon that automatically mounts filesystems whenever a file or
>  directory within that filesystem is accessed.  Filesystems are automati-
>  cally unmounted when they appear to be quiescent.

Ahh, but that assumes that your AMD configuration has all systems and mount
points enumerated in it.  Let me see - I think that 30gig drive may be big
enough for that file :-)

> > and have it work.  That would be nice.  (Replace the above with
> > ftp: or http: or whatever other protocol would provide read and/or write
> > access.)
> 
> What you're looking for is a substitute open() function.  Perhaps
> someone should just write a URI base library.  Put it in the public
> domain, of course, so that all UR base is belong to us

Ahh, but that does not address all software.  Sure, edit all source and
make the call to open() now be a call to uri_open()...  Why bother making
the OS deal with the issues involved?

The reason the OS should (and could) is that it is the base from which
all such services grow.  Now, in a microkernel design (such as the
previously mentioned HURD) there are ways to extend the filesystem to
include new types (FTPFS is a great example of such a filter/expansion)
but in FreeBSD (very much not microkernel) this then becomes an OS
issue or a user-program issue.  If it is in user space you end up with
"some have it" and "some don't" and "some have some subset" which
makes it really nasty.

Can you imagine if there was an ide_open() to open files on IDE drives
and a scsi_open() to open files on SCSI drives?  Or a UFS_open() vs an
ext2_open() vs an FFS_open()?  Why would you then want a uri_open()
vs regular open()?

> 

Watch those puns - I could end up returning them unopened :-)

-- 
Michael Sinz  Worldgate Communications  [EMAIL PROTECTED]
A master's secrets are only as good as
the master's ability to explain them to others.

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

Re: Should URL's be pervasive.

[Michael Sinz]

Chris Costello wrote:
> 
> On Friday, August 31, 2001, Michael Sinz wrote:
> > I too have been hoping for (and building internal tools) that work
> > this way.  I really wish you could just do:
> >
> >   open("nfs://server.name.dom/directory/file.txt")
> >
> > and have it work.  That would be nice.  (Replace the above with
> > ftp: or http: or whatever other protocol would provide read and/or write
> > access.)
> >
> > Anyway, I don't see it happening quickly but I don't see it as a bad thing
> > and I would guess that it will eventually get to that point.  (The network
> > includes your local machine so why not)
> 
>Whatever happened to not distinguishing different types of file
> systems from one another in pathnames?  And are you suggesting that
> we add network overhead (I'd still imagine lo0 can't help speeding
> things up...) to file system accesses?

What I was trying to say is that there is no reason that I should care
if the file is local or not.  Why should a program have to specifically
offer support to edit that file from an FTP site.  (EMACS and other editors
have added transparent FTP support, but that was extra work for them)

Just as the OS support having multiple storage devices and media and the
software does not need to know if the file is on a SCSI or IDE disk or if
it is on DISK 2 partition 3 or DISK 5 partition 1, why should it know if
it is local or on the machine beside it or on the machine on the other side
of the world?

Now, the OS (from a technical level) should be smart enough to handle not
doing actual NFS (or FTP or HTTP or whatever protocol) to its local disk
when it can.  (Sometimes going in via FTP to the local machine gets you
in as a different user and thus gets you different access rights so the
level of complexity is not always obviously trivial)

Anyway, the point is that a file that I can access should be a file I
can access via VI or MORE or EMACS or GREP or any other tool without
having those tools each having FTP and HTTP and SSH support built in to
them.  The OS should handle it.

-- 
Michael Sinz  Worldgate Communications  [EMAIL PROTECTED]
A master's secrets are only as good as
the master's ability to explain them to others.

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

Re: Junior Kernel Hacker task: improve vnode->v_tag

[Mark Santcroos]

On Tue, Sep 04, 2001 at 02:27:00PM +0200, Poul-Henning Kamp wrote:
> >I've done a /cursory/ look over how this v_tag is used.  I'm not sure
> >this is a simple/clean as you propose, since this is used in the 
> >IS_LOCKING_VFS macro, as well as in union_subr.c...
> 
> Well, that is just too bad, because IS_LOCKING_VFS is wrong then.

That's what the line of comment above it said ;)

/*
 * [dfr] Kludge until I get around to fixing all the vfs locking.
 */


Mark

-- 
Mark Santcroos  RIPE Network Coordination Centre
http://www.ripe.net/home/mark/  New Projects Group/TTM

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

Re: Junior Kernel Hacker task: improve vnode->v_tag

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Brent Verner writes:
>On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote:
>| 
>| Assignment:
>| 
>| The v_tag element in struct vnode is a debugging aid, but unfortunately
>| it is implemented in a way which means that adding a filesystem means
>| modifying the definition in .
>| 
>| Convert the v_tag to an "const char *" and have the filesystems put
>| their name in there instead.
>| 
>| The v_tag has been abused a few places, easily recognizable by the fact
>| that the kernel should never inspect the value of v_tag.
>| These places should be easily changeable to use the new representation.
>| Please mark them with a big fat "/*XXX: ABUSE OF v_tag */" comment.
>
>#include 
>
>I've done a /cursory/ look over how this v_tag is used.  I'm not sure
>this is a simple/clean as you propose, since this is used in the 
>IS_LOCKING_VFS macro, as well as in union_subr.c...

Well, that is just too bad, because IS_LOCKING_VFS is wrong then.

The places which inspect v_tag will have to be changed to use
strcmp() then...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

Re: Junior Kernel Hacker task: improve vnode->v_tag

[Brent Verner]

On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote:
| 
| Assignment:
| 
| The v_tag element in struct vnode is a debugging aid, but unfortunately
| it is implemented in a way which means that adding a filesystem means
| modifying the definition in .
| 
| Convert the v_tag to an "const char *" and have the filesystems put
| their name in there instead.
| 
| The v_tag has been abused a few places, easily recognizable by the fact
| that the kernel should never inspect the value of v_tag.
| These places should be easily changeable to use the new representation.
| Please mark them with a big fat "/*XXX: ABUSE OF v_tag */" comment.

#include 

I've done a /cursory/ look over how this v_tag is used.  I'm not sure
this is a simple/clean as you propose, since this is used in the 
IS_LOCKING_VFS macro, as well as in union_subr.c...

These uses /seem/ fairly significant due to the fact that the v_tag
is being used to determine capabilities of the vnode in question.
How should this be worked around?  It would be fairly trivial to
change v_tag to v_feature (or similar) then add the v_tag as you
propose.  I suggest this since those _tests_ for features should
IMO not be done with a char[] operation, since that would (in my
ignorant estimation) have a very negative effect on fs performance.

Of course, my suggested v_feature hack would again require changing
vnode.h for new features, but this is (assumedly) less frequent 
than modifying for file systems.

I'll work on this this weekend, and (hopefully) follow thru with
a patch.

cheers.
  Brent

-- 
"Develop your talent, man, and leave the world something. Records are 
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing."  -- Duane Allman

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

subscriber incoming

[Tim Allshorn]

subscribe freebsd-hackers

_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


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

ipnat, ipf, ipfstat devices not configured

[Chojin]

Hello,

Since  I recompiled my system and kernel (4.3-RELEASE) I can't use ipnat ipf
and ipfstat:

#ipnat
/dev/ipnat: open: Device not configured

#ipf -Fa -f /etc/ipf.rules
open device: Device not configured
ioctl(SIOCIPFFL): Bad file descriptor
open device: Device not configured
2:ioctl(add/insert rule): Bad file descriptor
3:ioctl(add/insert rule): Bad file descriptor

#ipfstat
open: Device not configured

I did all things needed as MAKEDEV all (done by mergemaster).

There are all options unchanged in my kernel configuration file:
options IPFILTER#ipfilter support
options IPFILTER_LOG#ipfilter logging
options IPFIREWALL
options IPFIREWALL_VERBOSE_LIMIT=100#limit verbosity
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPDIVERT

I don't understand why there is this problem.
Anyone could help me ?

Chojin


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

Re: Snmp problems

[Chojin]

Problems started since yesterday and last time I modified community and
other things few weeks ago.
When I try to cfgmaker, it displays the same errors.

- Original Message -
From: "Kelvin Ng Chee Hoong" <[EMAIL PROTECTED]>
To: "Chojin" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, September 04, 2001 12:02 PM
Subject: Re: Snmp problems


> Do your community string correct  ? Do you change community string
> recently ? Do you configure [Target] tag  in mrtg.conf  point to correct
> MIB ?
>
>
> Chojin wrote:
>
> >Hello,
> >
> >Since yesterday, when I do /usr/local/bin/mrtg
/usr/local/etc/mrtg/mrtg.cfg
> >It says:
> >SNMP Error:
> >no response received
> >SNMPv1_Session (remote host: "127.0.0.1" [127.0.0.1].161)
> >  community: "TMRTGCHO"
> > request ID: 1484981548
> >PDU bufsize: 8000 bytes
> >timeout: 2s
> >retries: 5
> >backoff: 1)
> > at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450
> >SNMPGET Problem for ifInOctets.1 ifOutOctets.1 sysUptime sysName on
> >[EMAIL PROTECTED]:
> > at /usr/local/bin/mrtg line 1485
> >WARNING: Expected a number but got ''
> >WARNING: Expected a number but got ''
> >
> >SNMP Error:
> >no response received
> >SNMPv1_Session (remote host: "127.0.0.1" [127.0.0.1].161)
> >  community: "TMRTGCHO"
> > request ID: 1484981549
> >PDU bufsize: 8000 bytes
> >timeout: 2s
> >retries: 5
> >backoff: 1)
> > at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450
> >SNMPGET Problem for ifInOctets.2 ifOutOctets.2 sysUptime sysName on
> >[EMAIL PROTECTED]:
> > at /usr/local/bin/mrtg line 1485
> >WARNING: Expected a number but got ''
> >WARNING: Expected a number but got ''
> >...
> >
> >It's very strange because I didn't modify anything on snmp configuration.
> >Then I can't have trafic stats for my interfaces...
> >
> >I killed and restarted snmpd but no change.
> >
> >Anyone has got an idea ?
> >
> >Regards,
> >
> >Chojin
> >
> >
> >To Unsubscribe: send mail to [EMAIL PROTECTED]
> >with "unsubscribe freebsd-questions" in the body of the message
> >
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-questions" in the body of the message
>


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

Re: Snmp problems

[Kelvin Ng Chee Hoong]

Do your community string correct  ? Do you change community string 
recently ? Do you configure [Target] tag  in mrtg.conf  point to correct 
MIB ?


Chojin wrote:

>Hello,
>
>Since yesterday, when I do /usr/local/bin/mrtg /usr/local/etc/mrtg/mrtg.cfg
>It says:
>SNMP Error:
>no response received
>SNMPv1_Session (remote host: "127.0.0.1" [127.0.0.1].161)
>  community: "TMRTGCHO"
> request ID: 1484981548
>PDU bufsize: 8000 bytes
>timeout: 2s
>retries: 5
>backoff: 1)
> at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450
>SNMPGET Problem for ifInOctets.1 ifOutOctets.1 sysUptime sysName on
>[EMAIL PROTECTED]:
> at /usr/local/bin/mrtg line 1485
>WARNING: Expected a number but got ''
>WARNING: Expected a number but got ''
>
>SNMP Error:
>no response received
>SNMPv1_Session (remote host: "127.0.0.1" [127.0.0.1].161)
>  community: "TMRTGCHO"
> request ID: 1484981549
>PDU bufsize: 8000 bytes
>timeout: 2s
>retries: 5
>backoff: 1)
> at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450
>SNMPGET Problem for ifInOctets.2 ifOutOctets.2 sysUptime sysName on
>[EMAIL PROTECTED]:
> at /usr/local/bin/mrtg line 1485
>WARNING: Expected a number but got ''
>WARNING: Expected a number but got ''
>...
>
>It's very strange because I didn't modify anything on snmp configuration.
>Then I can't have trafic stats for my interfaces...
>
>I killed and restarted snmpd but no change.
>
>Anyone has got an idea ?
>
>Regards,
>
>Chojin
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-questions" in the body of the message
>



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

Snmp problems

[Chojin]

Hello,

Since yesterday, when I do /usr/local/bin/mrtg /usr/local/etc/mrtg/mrtg.cfg
It says:
SNMP Error:
no response received
SNMPv1_Session (remote host: "127.0.0.1" [127.0.0.1].161)
  community: "TMRTGCHO"
 request ID: 1484981548
PDU bufsize: 8000 bytes
timeout: 2s
retries: 5
backoff: 1)
 at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450
SNMPGET Problem for ifInOctets.1 ifOutOctets.1 sysUptime sysName on
[EMAIL PROTECTED]:
 at /usr/local/bin/mrtg line 1485
WARNING: Expected a number but got ''
WARNING: Expected a number but got ''

SNMP Error:
no response received
SNMPv1_Session (remote host: "127.0.0.1" [127.0.0.1].161)
  community: "TMRTGCHO"
 request ID: 1484981549
PDU bufsize: 8000 bytes
timeout: 2s
retries: 5
backoff: 1)
 at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450
SNMPGET Problem for ifInOctets.2 ifOutOctets.2 sysUptime sysName on
[EMAIL PROTECTED]:
 at /usr/local/bin/mrtg line 1485
WARNING: Expected a number but got ''
WARNING: Expected a number but got ''
...

It's very strange because I didn't modify anything on snmp configuration.
Then I can't have trafic stats for my interfaces...

I killed and restarted snmpd but no change.

Anyone has got an idea ?

Regards,

Chojin


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

Re: general ethernet driver changes

[Terry Lambert]

Luigi Rizzo wrote:
> 
> > Did you have opportunity to play with the soft interrupt
> > coalescing we discussed?
> 
> Did this message just leak to a mailing list, or would you
> be able to expand this (or pass a pointer to mailing lists
> where this was discussed) ?

Ignore the man behind the curtain... 8-)

Seriously, it was at two BABUG (Bay Area BSD User's Group)
meetings; no big secret.

-- Terry

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

Junior Kernel Hacker task: improve vnode->v_tag

[Poul-Henning Kamp]

Assignment:

The v_tag element in struct vnode is a debugging aid, but unfortunately
it is implemented in a way which means that adding a filesystem means
modifying the definition in .

Convert the v_tag to an "const char *" and have the filesystems put
their name in there instead.

The v_tag has been abused a few places, easily recognizable by the fact
that the kernel should never inspect the value of v_tag.
These places should be easily changeable to use the new representation.
Please mark them with a big fat "/*XXX: ABUSE OF v_tag */" comment.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

Re: What is VT_TFS?

[Terry Lambert]

Julian Elischer wrote:
> > > What is the file system that uses VT_TFS in vnode.h? Is it
> > > still available on FreeBSD?  Thanks.
> >
> > Julian added it for TRW Financial Services; the first public
> > reference machine for 386BSD (which later became FreeBSD and
> > NetBSD) was ref.tfs.com.  TRW supported a lot of the early
> > 386BSD/FreeBSD effort, back before Walnut Creek CDROM threw
> > in and had us change the version number from 0.1 to 1.0 to
> > make it a bit easier to sell.  The version numbers have been
> > bloating ever since...
> 
> I think you are thinking of other stuff I did at TFS, (we had
> something similar) but never committed here.. this was actually
> done in the following commit:

Hunh.  I could have sworn that that was your baby...  I guess
I'm just remembering a conversation about the "something similar".

In any case, it's useful to let a VFS layer "own" its vnodes...
so I'd leave it there: never know when you might need it.

-- Terry

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

Re: virtual consoles

[Peter Pentchev]

On Tue, Sep 04, 2001 at 11:37:39AM +0800, Igor Podlesny wrote:
[snip]
> 
> Screen is a nice thing, I agree. Just one drawback is (Ctrl-A)*N
> consoles (i.e., when you use screen at local console, than log in
> into another box and run screen there. Local screen will see catch
> Ctrl-A and you're forced to type it twice or even more times :)

And then, of course, there is always the 'escape' screenrc command,
allowing you to set a different command character for each session :)
Though.. this would probably lead to a nightmare of misdirected key
presses..  But still, it is there.

G'luck,
Peter

-- 
I am not the subject of this sentence.

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