Date: Wed, 27 Nov 1996 14:29:24 -0500 From: Lotus_Mail_Exchange@CSERVE4.CCMAIL.compuserve.com To: "INTERNET:hackers@freefall.freebsd.org" <hackers@freefall.freebsd.org> Subject: NON-DELIVERY of: hackers-digest V1 #1669 Message-ID: <199611271443_MC1-BCB-65A2@compuserve.com>
next in thread | raw e-mail | index | archive | help
Sender: owner-hackers-digest@freefall.freebsd.org
Received: from ns2.harborcom.net (ns2.harborcom.net [206.158.4.4]) by arl-img-5.compuserve.com (8.6.10/5.950515)
id OAA28079; Fri, 22 Nov 1996 14:22:04 -0500
From: <owner-hackers-digest@freefall.freebsd.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.18]) by ns2.harborcom.net (8.8.3/8.8.3) with ESMTP id OAA06054; Fri, 22 Nov 1996 14:18:39 -0500 (EST)
Received: (from root@localhost)
by freefall.freebsd.org (8.7.5/8.7.3) id KAA09613
for freebsd-hackers-digest-outgoing; Fri, 22 Nov 1996 10:48:25 -0800 (PST)
Date: Fri, 22 Nov 1996 10:48:25 -0800 (PST)
Message-Id: <199611221848.KAA09613@freefall.freebsd.org>
To: freebsd-hackers-digest@FreeBSD.ORG
Subject: hackers-digest V1 #1669
Reply-To: hackers@freefall.freebsd.org
Errors-To: owner-hackers-digest@freefall.freebsd.org
Precedence: bulk
hackers-digest Friday, 22 November 1996 Volume 01 : Number 1669
In this issue:
INET aliases and BIND
INET aliases and NAMED
Re: Who needs Perl? We do!
Re: INET aliases and BIND
Re: INET aliases and BIND
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
Re: INET aliases and NAMED
Re: undump or unexec
Re: Pentium Pro status
Re: panic: ffs_valloc: dup alloc
Driver for Intel EtherExpress Pro/10
Re: ATAPI (was: Who needs Perl? We do!)
Re: Who needs Perl? We do!
Re: Driver for Intel EtherExpress Pro/10
Re: Drive with 1024 byte logical blocks
----------------------------------------------------------------------
From: Joe Karthauser <jlk@pavilion.co.uk>
Date: Fri, 22 Nov 1996 11:15:28 +0000 (GMT)
Subject: INET aliases and BIND
Hello,
I've got an interesting question to do with BIND running on a machine
with IP aliases.
My machine is running FreeBSD2.1.5 (straight off the CD) and has an
entire class C of /32 inet aliases attached to the ethernet card. This
is to facilitate a batch of virtual ftp servers. The problem is this.
I also want to run named on the machine, and when I start it I get:
Nov 22 10:32:40 dougal named[2019]: starting. named LOCAL-960717.011537 Wed Jul 17 01:15:37 1996 jkh@whisker.cdrom.com:/usr/src/usr.sbin/named
Nov 22 10:32:40 dougal named[2019]: socket(SOCK_DGRAM): Too many open files - exiting
I guess that named doesn't like binding inaddrany, how can this be solved?
Cheers in advance for any help,
All the best,
Joe.
- --
Josef Karthauser (jlk@pavilion.net)
Technical Manager [Tel: +44 1273 607072 Fax: +44 1273 607073]
Pavilion Internet plc. ._ .. _. _ ._.. .. .._. . __. ._. ._ _. _..
------------------------------
From: Joe Karthauser <jlk@pavilion.co.uk>
Date: Fri, 22 Nov 1996 11:19:29 +0000 (GMT)
Subject: INET aliases and NAMED
Hi,
Oops I forgot to add, I only want named bound to one IP address, not
the whole lot.
Cheers,
Joe.
- --
Josef Karthauser (jlk@pavilion.net)
Technical Manager [Tel: +44 1273 607072 Fax: +44 1273 607073]
Pavilion Internet plc. ._ .. _. _ ._.. .. .._. . __. ._. ._ _. _..
------------------------------
From: Paul Richards <p.richards@elsevier.co.uk>
Date: 22 Nov 1996 11:33:30 +0000
Subject: Re: Who needs Perl? We do!
Terry Lambert <terry@lambert.org> writes:
> Actually, you use sh to run /etc/rc* each time you boot. It is a
> minimal system component, mostly because the data and the procedure
> for system startup have not been sufficiently abstracted. If they
> had, you could replace the startup procedure with a binary and throw
> /bin/sh away.
I tend to agree. Obviously I know that /bin/sh is used for startup but
we could replace it with perl :-)
- --
Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor)
Elsevier Science TIS online journal project.
Email: p.richards@elsevier.co.uk
Phone: 0370 462071 (Mobile), +44 (0)1865 843155
------------------------------
From: Joe Greco <jgreco@brasil.moneng.mei.com>
Date: Fri, 22 Nov 1996 06:16:29 -0600 (CST)
Subject: Re: INET aliases and BIND
> Hello,
>
> I've got an interesting question to do with BIND running on a machine
> with IP aliases.
>
> My machine is running FreeBSD2.1.5 (straight off the CD) and has an
> entire class C of /32 inet aliases attached to the ethernet card. This
> is to facilitate a batch of virtual ftp servers. The problem is this.
> I also want to run named on the machine, and when I start it I get:
>
> Nov 22 10:32:40 dougal named[2019]: starting. named LOCAL-960717.011537 Wed Jul 17 01:15:37 1996 jkh@whisker.cdrom.com:/usr/src/usr.sbin/named
> Nov 22 10:32:40 dougal named[2019]: socket(SOCK_DGRAM): Too many open files - exiting
>
> I guess that named doesn't like binding inaddrany, how can this be solved?
>
> Cheers in advance for any help,
> All the best,
> Joe.
named opens a separate socket for each (virtual) interface it finds.
You might need to change the invocation to something like "csh -c unlimit
descriptors; named", as you are probably banging into the per process
descriptor limit.
... JG
------------------------------
From: Joe Karthauser <jlk@pavilion.co.uk>
Date: Fri, 22 Nov 1996 12:33:17 +0000 (GMT)
Subject: Re: INET aliases and BIND
This hits the mark, Thanks.
Joe.
>
> > Hello,
> >
> > I've got an interesting question to do with BIND running on a machine
> > with IP aliases.
> >
> > My machine is running FreeBSD2.1.5 (straight off the CD) and has an
> > entire class C of /32 inet aliases attached to the ethernet card. This
> > is to facilitate a batch of virtual ftp servers. The problem is this.
> > I also want to run named on the machine, and when I start it I get:
> >
> > Nov 22 10:32:40 dougal named[2019]: starting. named LOCAL-960717.011537 Wed Jul 17 01:15:37 1996 jkh@whisker.cdrom.com:/usr/src/usr.sbin/named
> > Nov 22 10:32:40 dougal named[2019]: socket(SOCK_DGRAM): Too many open files - exiting
> >
> > I guess that named doesn't like binding inaddrany, how can this be solved?
> >
> > Cheers in advance for any help,
> > All the best,
> > Joe.
>
> named opens a separate socket for each (virtual) interface it finds.
>
> You might need to change the invocation to something like "csh -c unlimit
> descriptors; named", as you are probably banging into the per process
> descriptor limit.
>
> ... JG
>
- --
Josef Karthauser (jlk@pavilion.net)
Technical Manager [Tel: +44 1273 607072 Fax: +44 1273 607073]
Pavilion Internet plc. ._ .. _. _ ._.. .. .._. . __. ._. ._ _. _..
------------------------------
From: Paul Richards <p.richards@elsevier.co.uk>
Date: 22 Nov 1996 13:26:16 +0000
Subject: Re: Who needs Perl? We do!
Nate Williams <nate@mt.sri.com> writes:
> But the policy is that nothing belongs in the 'src' tree unless
> something else relies on it. You can get TCL via the ports (or could
> have until we brought it into the tree) and it should have stayed there
> since nothing still uses it and it's been over 5 months. I complained
> when it was brought in and was told 'Real Soon Now', but nothing has
> happened.
Who says? There are lots of things in the src tree that are not
normally used, with nothing depending on them.
> It's simply bloat that is useless to *most* users, and has no use in the
> main tree. I'm willing to be proven wrong, but unless that happens soon
> I'm gonna stay in the 'complain and moan' camp. (I *HATE* seeing stupid
> TCL man-pages that come up instead of the C routines).
(The man pages annoy me too, couldn't we get them into a different
section).
"Most" users is I guess the key issue and it seems from this
discussion that "most" users user perl.
- --
Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor)
Elsevier Science TIS online journal project.
Email: p.richards@elsevier.co.uk
Phone: 0370 462071 (Mobile), +44 (0)1865 843155
------------------------------
From: Paul Richards <p.richards@elsevier.co.uk>
Date: 22 Nov 1996 13:29:52 +0000
Subject: Re: Who needs Perl? We do!
Nate Williams <nate@mt.sri.com> writes:
> Let's see those tools, and then I'll shutup. Again, there are lots of
> *useful* things that we could bring in, but they aren't used and/or
> essential. Should we bring in Python as well, and what about the new
> Limbo compiler from the folks at Lucent (nee Bell Labs). What about the
> ADA compiler from the GNU folks? Where do you draw the line between
> 'useful to some' and 'bloat'.
When "some" becomes a significant percentage of "users".
> It was decided a *LONG* time ago that unless a utility was part of the
> standard BSD distribution and/or was required for the running system it
> shouldn't be part of the tree.
I don't ever recall this.
> 'libforms' was recently deleted since it was a 'good idea' that never
> came to pass. It might have been a useful tool, but *FreeBSD* doesn't
> use it.
Hell, even I don't use it and I wrote it. It should never have gone
into the tree in the first place but people have differing opinions
about how to use cvs and at the time it was a way to get the code
shared amongst the developers.
- --
Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor)
Elsevier Science TIS online journal project.
Email: p.richards@elsevier.co.uk
Phone: 0370 462071 (Mobile), +44 (0)1865 843155
------------------------------
From: Joe Greco <jgreco@brasil.moneng.mei.com>
Date: Fri, 22 Nov 1996 08:32:12 -0600 (CST)
Subject: Re: INET aliases and NAMED
> Hi,
>
> Oops I forgot to add, I only want named bound to one IP address, not
> the whole lot.
>
> Cheers,
> Joe.
Sorry, I did not see this :-)
There is no way that I know of to do this, without source hackery.
What you probably want to do is butcher getnetconf(). I would probably
consider copying the lines that skip 0.0.0.0 and modify it to skip all
alias addresses you have. I have not tried this, however.
Your other alternative is to avoid running a name server on this box.
... JG
------------------------------
From: Darius Moos <moos@degnet.baynet.de>
Date: Fri, 22 Nov 1996 15:35:14 -0100
Subject: Re: undump or unexec
I've tried it and the resulting executable does not work correct.
The source-perl-script uses stdin and stdout a lot. byteperl seems to
garble some of the output.
Any suggestions ???
Darius Moos.
Jonathan Lemon wrote:
>
> > following this discussion the last days, i was wondering if anyone
> > got "undump" compiled ?
>
> I'll go out on a limb here and guess that you're trying to undump a perl
> executable. If this is the case, then you may want to check out the
> perl compiler (see www.perl.com).
> --
> Jonathan
>
> PS: FWIW, I never did get undump to work properly with perl4.
------------------------------
From: "Jin Guojun[ITG]" <jin@george.lbl.gov>
Date: Fri, 22 Nov 1996 07:41:16 -0800
Subject: Re: Pentium Pro status
} > Pentinum.
} > Some more performance comparsion willbe found on:
} >
} > ftp://george.lbl.gov/pub/ccs/performance.ps (p6-7 for P<-->PP).
} > It will be updated whenever the new board/machines come in.
}
} Do you mind upgrading your P6 to FreeBSD-2.2 and then running the
} benchmarks.
}
} Tnks,
} Amancio
The P6 result updated yesterday is under 2.2-Alpha.
- -Jin
------------------------------
From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Date: Fri, 22 Nov 1996 09:31:37 -0500 (EST)
Subject: Re: panic: ffs_valloc: dup alloc
>
> Thomas David Rivers wrote in message ID
> <199611161253.HAA26583@lakes.water.net>:
> > > root@mail:/var/crash> gdb -k kernel vmcore.2
> > > GDB is free software and you are welcome to distribute copies of it
> > > under certain conditions; type "show copying" to see the conditions.
> > > There is absolutely no warranty for GDB; type "show warranty" for details.
> > > GDB 4.13 (i386-unknown-freebsd),
> > > Copyright 1994 Free Software Foundation, Inc...
> > > IdlePTD 1d5000
> > > current pcb at 1abd64
> > > panic: ffs_valloc: dup alloc
> > > #0 boot (howto=260) at ../../i386/i386/machdep.c:912
> > > 912 } else {
> > > (kgdb) bt
>
> > Welcome to the club :-)
>
> > This is the panic that I have had for several months, which is
> > duplicated almost every night.
>
> Well, it just bit me again :-(
The panic happens for me almost nightly.
>
> > Rest assured that several people are investigating this at this
> > time...
>
> > I believe it has something to do with the inode allocation bits in
> > ffs_valloc(). Others believe some race conditions in vnode allocation
> > are to blaim, etc... David Greene is investigating other avenues.
>
> > It seems to me that we are closing in on the issue, if only by
> > eliminating everything else :-)
>
> Question:
>
> it's always the same FS with me that bites the dust. Perhaps a
> previous crash of the machine caused a FS corruption fsck isn't
> picking up on. Has anyone who is being bothered by this dumped the fs
> with *tar* (not dump) and resored to see if that fixes the problem?
I completely reinstalled everything (wiped the disk, even did
a low-level SCSI format) - the problem always resurfaced. Although,
it didn't show up again for maybe two or three days.
- Dave Rivers -
------------------------------
From: Javier Martin Rueda <jmrueda@diatel.upm.es>
Date: Fri, 22 Nov 1996 18:32:10 UTC+0100
Subject: Driver for Intel EtherExpress Pro/10
Hello.
One week ago, more or less, I posted a message into this list saying that I
had written a driver for the Intel EtherExpress Pro/10 network card, both for
FreeBSD 2.1.5, and for FreeBSD 2.2. I also uploaded it to the incoming
directory of ftp.freebsd.org, with name if_ex-961115.tar.gz-INDENTED.
According to the handbook, when you do those things, someone will very likely
contact you, but, so far, nobody has done that. So, I don't know if you have
not seen it, if it is ok to include it in the source code tree, if I should do
anything else, or what.
Don't take this as an annoyment message. I know you probably are quite busy,
so it's just to remind, in case it was skipped last time. :-)
------------------------------
From: Mark Mayo <mark@quickweb.com>
Date: Fri, 22 Nov 1996 12:49:55 -0500 (EST)
Subject: Re: ATAPI (was: Who needs Perl? We do!)
On Thu, 21 Nov 1996, Soren Schmidt wrote:
> In reply to Paul Richards who wrote:
> >=20
> >=20
> > Soren Schmidt <sos@ravenock.cybercity.dk> writes:
> >=20
> > > I have a very good example, I stated some month back that I'd
> > > take reponsibility of the atapi/ide driver and do a rewrite,=20
> > > because there was ALOT of talk about how miserable our current
> > > implementation was. I also stated that in order to do that I=20
> > > needed some samples of atapi/ide equipment as I dont have the
> > > funding for doing that (and given I had I'd buy SCSI :) )
> > > but I didn't get ONE single reponse of that kind, no sir, but
> > > I got alot of "let me test it, gimme, gimme, gimme".
>=20
> Catch-22...
>=20
> > I'd be encouraged by the fact that a lot of people were willing to
> > volunteer their time to test it.
>=20
> Sure, but it doesn't work that way unfortunately...
Okay, I'll send you a couple IDE CDROM drives -- I emailed you during your
original offer about the brands I have, but you didn't indicate which
models you were interested in. I have a Creative Labs 4X, a PIONEER 4X,
and a Funai 4X that I'm willing to part with. One thing though, if I
remember correctly you're in Europe S'ren, correct? Where exactly, cause
it might be more expensive to send the drives than to just send you some
cash to buy new units.. how much do 4X ATAPI CDROMs cost where you are?
I'm only a 21 year old univeristy student with a very low budget, but
nothing irrates me more than having to recomend Linux to friends instead
of FreeBSD because they have IDE CDROMs.... hence, I'll empty my pocket to
help out. I also think it would really SUCK to release 2.2 without even
slightly improved ATAPI support; Reality check: _ALL_ PC's sold these days
ship with ATAPI CDROM drives.....
Also, I'll be coming over to France for Christmas (my girlfriend is
French) - if you're close by I can hand deliver the drives to you, it
would probably by cheaper than sending them through Canada Post.
cya,
- -mark
>=20
> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
- -=3D-
> S=F8ren Schmidt (sos@FreeBSD.org) FreeBSD Cor=
e Team
> Even more code to hack -- will it ever end
> ..
>=20
- ---------------------------------------------------
| Mark Mayo=09=09 mark@quickweb.com |
| RingZero Comp. =09 vinyl.quickweb.com/mark |
- ---------------------------------------------------
"To iterate is human, to recurse divine."
=09=09- L. Peter Deutsch
------------------------------
From: Terry Lambert <terry@lambert.org>
Date: Fri, 22 Nov 1996 10:50:00 -0700 (MST)
Subject: Re: Who needs Perl? We do!
[ ... Joerg, in response to Richard ... ]
> There's nothing like "core" that can be attributed this way, as if it
> were a single person, in FreeBSD. There are only members of the core
> team who try to discuss several `government' issues on their mailing
> list, who often have (incidentally) agreeing opinions but also often
> disagreeing opinions about some technical matter, and who last but not
> least often spend quite a large amount of time on the project, not
> only for coding but for much more boring tasks like release
> engineering, user support etc.
>
> So pleas don't claim that "core" does/doesn't do this or that.
Have you heard the term "pocket veto"?
It comes from the process by which national laws are enacted in
the United States.
It's where a bill (a proposed law) has been passed by congress and
sent to the president for him to either sign into law (if he agrees
with it), or to veto (if he disagrees with it).
If the bill is vetoed, the congress can repass the bill with an
overwhelming majority, and it will become law anyway, over the
veto. This process is called "overriding a veto".
A president has a third option. If he neither signs, nor vetos,
a bill in a specified time period, the bill is considered to have
been vetoed. As if the president had put it in his pocket, and
forgotten about it.
A president may intentionally "pocket veto" a bill to delay the
process if he believes the driving force is public opinion or
otherwise caused by political expediency. This gives him time
to defuse the political situation providing the specific impulse
for the bill, and is a much more effective method of preventing
an override than an immediate veto would be.
Currently, there is no mechanism for "congress" (the contributors)
to "override" the president's (core's) "pocket veto".
To use a non-political analogy, the core team is engaging in
source quench, when its job is to provide a comitted bandwidth.
Failure to live up to this commitment is topologically equivalent to
a "pocket veto".
Regards,
Terry Lambert
terry@lambert.org
- ---
Any opinions in this posting are my own and not those of my present
or previous employers.
------------------------------
From: Mark Mayo <mark@quickweb.com>
Date: Fri, 22 Nov 1996 13:31:35 -0500 (EST)
Subject: Re: Driver for Intel EtherExpress Pro/10
On Fri, 22 Nov 1996, Javier Martin Rueda wrote:
> Hello.
>
> One week ago, more or less, I posted a message into this list saying that I
> had written a driver for the Intel EtherExpress Pro/10 network card, both for
> FreeBSD 2.1.5, and for FreeBSD 2.2. I also uploaded it to the incoming
> directory of ftp.freebsd.org, with name if_ex-961115.tar.gz-INDENTED.
>
> According to the handbook, when you do those things, someone will very likely
> contact you, but, so far, nobody has done that. So, I don't know if you have
> not seen it, if it is ok to include it in the source code tree, if I should do
> anything else, or what.
>
> Don't take this as an annoyment message. I know you probably are quite busy,
> so it's just to remind, in case it was skipped last time. :-)
>
I know I'd ceratinly be a happy camper to see this driver get
incorporated!! I have a few Intel cards lying in a drawer that I'd love to
be able to use. I'll grab the driver tonight, plop in the Intel card,
and see if
it works for me. -- I'm just a lame user though, you'll have to get the
attention of one of the 'commiters' for the driver to make it into the
main source tree.
- -Mark
- ---------------------------------------------------
| Mark Mayo mark@quickweb.com |
| RingZero Comp. vinyl.quickweb.com/mark |
- ---------------------------------------------------
"To iterate is human, to recurse divine."
- L. Peter Deutsch
>
------------------------------
From: "barry (b.a.) scott" <tsbarry@nortel.ca>
Date: 22 Nov 1996 06:11 EST
Subject: Re: Drive with 1024 byte logical blocks
The changes that John Gumb and I came up with modify
far less code then this patch. Is this patch fixing
extra problems that we missed?
Further you have not patched fdisk or newfs that seem to
be critical to getting a ufs file system onto a disk.
For reference here is our patches to sbin/... and sys/...
BArry
*** sys.orig/kern/subr_diskslice.c Sun Nov 17 19:55:47 1996
- --- sys/kern/subr_diskslice.c Tue Nov 19 20:09:26 1996
***************
*** 210,220 ****
- --- 210,224 ----
ic->ic_prev_iodone_chain = bp->b_iodone_chain;
ic->ic_args[0].ia_long = (LABELSECTOR + labelsect - blkno)
<< DEV_BSHIFT;
+ /* if we have a label then scale the offset to the disklabel */
+ if( lp )
+ ic->ic_args[0].ia_long *= lp->d_secsize / DEV_BSIZE;
ic->ic_args[1].ia_ptr = sp;
bp->b_flags |= B_CALL;
bp->b_iodone = dsiodone;
bp->b_iodone_chain = ic;
if (!(bp->b_flags & B_READ)) {
+
/*
* XXX even disklabel(8) writes directly so we need
* to adjust writes. Perhaps we should drop support
*** sys.orig/msdosfs/msdosfs_fat.c Sun Nov 17 19:54:36 1996
- --- sys/msdosfs/msdosfs_fat.c Tue Nov 19 20:09:34 1996
***************
*** 116,122 ****
* pmp->pm_BytesPerSec;
bn += pmp->pm_fatblk;
if (bnp)
! *bnp = bn;
if (sizep)
*sizep = size;
if (bop)
- --- 116,122 ----
* pmp->pm_BytesPerSec;
bn += pmp->pm_fatblk;
if (bnp)
! *bnp = bn * pmp->pm_SecBlkRatio;
if (sizep)
*sizep = size;
if (bop)
***************
*** 185,191 ****
return E2BIG;
}
if (bnp)
! *bnp = pmp->pm_rootdirblk + (findcn * pmp->pm_SectPerClust);
if (cnp)
*cnp = MSDOSFSROOT;
return 0;
- --- 185,191 ----
return E2BIG;
}
if (bnp)
! *bnp = (pmp->pm_rootdirblk + (findcn * pmp->pm_SectPerClust)) * pmp->pm_SecBlkRatio;
if (cnp)
*cnp = MSDOSFSROOT;
return 0;
***************
*** 340,346 ****
* bwrite()'s and really slow things down.
*/
for (i = 1; i < pmp->pm_FATs; i++) {
! fatbn += pmp->pm_FATsecs;
/* getblk() never fails */
bpn = getblk(pmp->pm_devvp, fatbn, bp->b_bcount, 0, 0);
bcopy(bp->b_data, bpn->b_data, bp->b_bcount);
- --- 340,346 ----
* bwrite()'s and really slow things down.
*/
for (i = 1; i < pmp->pm_FATs; i++) {
! fatbn += pmp->pm_FATsecs * pmp->pm_SecBlkRatio;
/* getblk() never fails */
bpn = getblk(pmp->pm_devvp, fatbn, bp->b_bcount, 0, 0);
bcopy(bp->b_data, bpn->b_data, bp->b_bcount);
*** sys.orig/msdosfs/msdosfs_vfsops.c Sun Nov 17 19:54:37 1996
- --- sys/msdosfs/msdosfs_vfsops.c Tue Nov 19 20:09:40 1996
***************
*** 273,278 ****
- --- 273,279 ----
struct buf *bp0 = NULL;
struct byte_bpb33 *b33;
struct byte_bpb50 *b50;
+ int secsize;
#ifdef PC98
u_int pc98_wrk;
u_int Phy_Sector_Size;
***************
*** 319,325 ****
devvp->v_flag &= 0xffff;
error = bread(devvp, 0, 1024, NOCRED, &bp0);
#else
! error = bread(devvp, 0, 512, NOCRED, &bp0);
#endif
if (error)
goto error_exit;
- --- 320,337 ----
devvp->v_flag &= 0xffff;
error = bread(devvp, 0, 1024, NOCRED, &bp0);
#else
! /* hunt for the sector size that works */
! for( secsize=DEV_BSIZE; secsize<=2048; secsize <<= 1 )
! {
! if( bp0 )
! {
! brelse( bp0 );
! bp0 = NULL;
! }
! error = bread(devvp, 0, secsize, NOCRED, &bp0);
! if( error == 0 )
! break;
! }
#endif
if (error)
goto error_exit;
***************
*** 349,354 ****
- --- 361,369 ----
pmp = malloc(sizeof *pmp, M_MSDOSFSMNT, M_WAITOK);
bzero((caddr_t)pmp, sizeof *pmp);
pmp->pm_mountp = mp;
+
+ /* calculate the ratio of sector size to DEV_BSIZE */
+ pmp->pm_SecBlkRatio = secsize/DEV_BSIZE;
/*
* Compute several useful quantities from the bpb in the
*** sys.orig/msdosfs/msdosfsmount.h Sun Nov 17 19:54:36 1996
- --- sys/msdosfs/msdosfsmount.h Tue Nov 19 20:09:43 1996
***************
*** 60,65 ****
- --- 60,66 ----
mode_t pm_mask; /* mask to and with file protection bits */
struct vnode *pm_devvp; /* vnode for block device mntd */
struct bpb50 pm_bpb; /* BIOS parameter blk for this fs */
+ int pm_SecBlkRatio; /* How many DEV_BSIZE blocks fit inside a physical sector */
u_long pm_fatblk; /* block # of first FAT */
u_long pm_rootdirblk; /* block # of root directory */
u_long pm_rootdirsize; /* size in blocks (not clusters) */
***************
*** 124,143 ****
* Map a cluster number into a filesystem relative block number.
*/
#define cntobn(pmp, cn) \
! ((((cn)-CLUST_FIRST) * (pmp)->pm_SectPerClust) + (pmp)->pm_firstcluster)
/*
* Map a filesystem relative block number back into a cluster number.
*/
#define bntocn(pmp, bn) \
! ((((bn) - pmp->pm_firstcluster)/ (pmp)->pm_SectPerClust) + CLUST_FIRST)
/*
* Calculate block number for directory entry in root dir, offset dirofs
*/
#define roottobn(pmp, dirofs) \
! (((dirofs) / (pmp)->pm_depclust) * (pmp)->pm_SectPerClust \
! + (pmp)->pm_rootdirblk)
/*
* Calculate block number for directory entry at cluster dirclu, offset
- --- 125,144 ----
* Map a cluster number into a filesystem relative block number.
*/
#define cntobn(pmp, cn) \
! (((((cn)-CLUST_FIRST) * (pmp)->pm_SectPerClust) + (pmp)->pm_firstcluster)*(pmp)->pm_SecBlkRatio)
/*
* Map a filesystem relative block number back into a cluster number.
*/
#define bntocn(pmp, bn) \
! (((((bn)/((pmp)->pm_SecBlkRatio) - pmp->pm_firstcluster)/ (pmp)->pm_SectPerClust) + CLUST_FIRST)
/*
* Calculate block number for directory entry in root dir, offset dirofs
*/
#define roottobn(pmp, dirofs) \
! ((((dirofs) / (pmp)->pm_depclust) * (pmp)->pm_SectPerClust \
! + (pmp)->pm_rootdirblk) * (pmp)->pm_SecBlkRatio)
/*
* Calculate block number for directory entry at cluster dirclu, offset
*** sys.orig/scsi/od.c Sun Nov 17 19:57:06 1996
- --- sys/scsi/od.c Tue Nov 19 20:09:46 1996
***************
*** 361,369 ****
switch (od->params.secsiz) {
case SECSIZE :
case 1024 :
- - #ifdef notyet
case 2048 :
- - #endif
break;
default :
printf("od%ld: Can't deal with %d bytes logical blocks\n",
- --- 361,367 ----
***************
*** 448,453 ****
- --- 446,452 ----
u_int32_t opri;
struct scsi_data *od;
u_int32_t unit;
+ int secsize;
odstrats++;
unit = ODUNIT((bp->b_dev));
***************
*** 464,478 ****
/*
* Odd number of bytes or negative offset
*/
! if (bp->b_blkno < 0 || bp->b_bcount % DEV_BSIZE != 0) {
bp->b_error = EINVAL;
goto bad;
}
/*
* Do bounds checking, adjust transfer, set b_cylin and b_pbklno.
*/
! if (dscheck(bp, od->dk_slices) <= 0)
goto done; /* XXX check b_resid */
opri = SPLOD();
- --- 463,520 ----
/*
* Odd number of bytes or negative offset
*/
! if (bp->b_blkno < 0 ) {
! bp->b_error = EINVAL;
! printf("od_strategy: Negative block number: 0x%x\n", bp->b_blkno);
! goto bad;
! }
!
!
! secsize = od->params.secsiz;
!
! /* make sure the blkno is scalable */
! if( (bp->b_blkno % (secsize/DEV_BSIZE)) != 0 ) {
bp->b_error = EINVAL;
+ printf("od_strategy: Block number is not multiple of sector size (2): 0x%x\n", bp->b_blkno);
goto bad;
}
+
+ /* make sure that the tranasfer size is a multiple of the sector size */
+ if( (bp->b_bcount % secsize) != 0 ) {
+ bp->b_error = EINVAL;
+ printf("od_strategy: Invalid b_bcount %d at block number: 0x%x\n", bp->b_bcount, bp->b_blkno);
+ goto bad;
+ }
+
/*
* Do bounds checking, adjust transfer, set b_cylin and b_pbklno.
*/
! {
! int status;
! int sec_blk_ratio = secsize/DEV_BSIZE;
! /* save original block number and size */
! int b_blkno = bp->b_blkno;
! int b_bcount = bp->b_bcount;
!
! /* replace with scaled values */
! bp->b_blkno /= sec_blk_ratio;
! bp->b_bcount /= sec_blk_ratio;
!
! /* have dscheck enforce limits and map to physical block number */
! status = dscheck(bp, od->dk_slices);
!
! /* restore original values to prevent bad side effects in block system */
! bp->b_blkno = b_blkno;
! bp->b_bcount = b_bcount;
! /* scale resid */
! bp->b_resid *= sec_blk_ratio;
!
! /* see if the mapping failed */
! if (status <= 0)
! {
goto done; /* XXX check b_resid */
+ }
+ }
opri = SPLOD();
***************
*** 581,592 ****
* With this thing..
*/
secsize = od->params.secsiz;
! blkno = bp->b_pblkno / (secsize / DEV_BSIZE);
if (bp->b_bcount & (secsize - 1))
{
goto bad;
}
! nblk = (bp->b_bcount + (secsize - 1)) / secsize;
/*
* Fill out the scsi command
- --- 623,634 ----
* With this thing..
*/
secsize = od->params.secsiz;
! blkno = bp->b_pblkno;
if (bp->b_bcount & (secsize - 1))
{
goto bad;
}
! nblk = bp->b_bcount / secsize;
/*
* Fill out the scsi command
*** sys.orig/ufs/ufs/ufs_disksubr.c Sun Nov 17 19:56:09 1996
- --- sys/ufs/ufs/ufs_disksubr.c Tue Nov 19 20:09:52 1996
***************
*** 182,188 ****
bp = geteblk((int)lp->d_secsize);
bp->b_dev = dev;
! bp->b_blkno = LABELSECTOR;
bp->b_bcount = lp->d_secsize;
bp->b_flags &= ~B_INVAL;
bp->b_flags |= B_BUSY | B_READ;
- --- 182,188 ----
bp = geteblk((int)lp->d_secsize);
bp->b_dev = dev;
! bp->b_blkno = LABELSECTOR * ((int)lp->d_secsize/DEV_BSIZE);
bp->b_bcount = lp->d_secsize;
bp->b_flags &= ~B_INVAL;
bp->b_flags |= B_BUSY | B_READ;
***************
*** 284,290 ****
}
bp = geteblk((int)lp->d_secsize);
bp->b_dev = dkmodpart(dev, labelpart);
! bp->b_blkno = LABELSECTOR;
bp->b_bcount = lp->d_secsize;
#if 1
/*
- --- 284,290 ----
}
bp = geteblk((int)lp->d_secsize);
bp->b_dev = dkmodpart(dev, labelpart);
! bp->b_blkno = LABELSECTOR * ((int)lp->d_secsize / DEV_BSIZE);
bp->b_bcount = lp->d_secsize;
#if 1
/*
*** sbin.orig/i386/fdisk/fdisk.c Wed Nov 20 11:18:24 1996
- --- sbin/i386/fdisk/fdisk.c Wed Nov 20 11:28:23 1996
***************
*** 54,60 ****
#define RoundCyl(x) ((((x) + cylsecs - 1) / cylsecs) * cylsecs)
! #define SECSIZE 512
const char *disk;
const char *disks[] =
- --- 54,62 ----
#define RoundCyl(x) ((((x) + cylsecs - 1) / cylsecs) * cylsecs)
! #define MAX_SEC_SIZE 2048 /* maximum section size that is supported */
! #define MIN_SEC_SIZE 512 /* the sector size to start sensing at */
! int secsize = 0; /* the sensed sector size */
const char *disk;
const char *disks[] =
***************
*** 74,79 ****
- --- 76,83 ----
unsigned char bootinst[DOSPARTOFF];
struct dos_partition parts[4];
unsigned short int signature;
+ /* room to read in MBRs that are bigger then DEV_BSIZE */
+ unsigned char large_sector_overflow[MAX_SEC_SIZE-MIN_SEC_SIZE];
};
struct mboot mboot;
***************
*** 292,297 ****
- --- 296,302 ----
if (read_s0())
init_sector0(1);
+ printf("Media sector size is %d\n", secsize );
printf("Warning: BIOS sector numbering starts with sector 1\n");
printf("Information from DOS bootblock is:\n");
if (partition == -1)
***************
*** 347,353 ****
printf("sysid %d,(%s)\n", partp->dp_typ, get_type(partp->dp_typ));
printf(" start %ld, size %ld (%ld Meg), flag %x\n",
partp->dp_start,
! partp->dp_size, partp->dp_size * 512 / (1024 * 1024),
partp->dp_flag);
printf("\tbeg: cyl %d/ sector %d/ head %d;\n\tend: cyl %d/ sector %d/ head %d\n"
,DPCYL(partp->dp_scyl, partp->dp_ssect)
- --- 352,358 ----
printf("sysid %d,(%s)\n", partp->dp_typ, get_type(partp->dp_typ));
printf(" start %ld, size %ld (%ld Meg), flag %x\n",
partp->dp_start,
! partp->dp_size, partp->dp_size * secsize / (1024 * 1024),
partp->dp_flag);
printf("\tbeg: cyl %d/ sector %d/ head %d;\n\tend: cyl %d/ sector %d/ head %d\n"
,DPCYL(partp->dp_scyl, partp->dp_ssect)
***************
*** 549,562 ****
read_disk(off_t sector, void *buf)
{
lseek(fd,(sector * 512), 0);
! return read(fd, buf, 512);
}
static ssize_t
write_disk(off_t sector, void *buf)
{
lseek(fd,(sector * 512), 0);
! return write(fd, buf, 512);
}
static int
- --- 554,582 ----
read_disk(off_t sector, void *buf)
{
lseek(fd,(sector * 512), 0);
!
! if( secsize == 0 )
! for( secsize = MIN_SEC_SIZE; secsize <= MAX_SEC_SIZE; secsize *= 2 )
! {
! /* try the read */
! int size = read(fd, buf, secsize);
! if( size == secsize )
! /* it worked so return */
! return secsize;
! }
! else
! return read( fd, buf, secsize );
!
! /* we failed to read at any of the sizes */
! return -1;
}
static ssize_t
write_disk(off_t sector, void *buf)
{
lseek(fd,(sector * 512), 0);
! /* write out in the size that the read_disk found worked */
! return write(fd, buf, secsize);
}
static int
*** sbin.orig/newfs/mkfs.c Wed Nov 20 11:20:40 1996
- --- sbin/newfs/mkfs.c Wed Nov 20 11:25:46 1996
***************
*** 82,90 ****
extern int nphyssectors; /* # sectors/track including spares */
extern int secpercyl; /* sectors per cylinder */
extern int sectorsize; /* bytes/sector */
- - #if defined( tahoe )
extern int realsectorsize; /* bytes/sector in hardware */
- - #endif
extern int rpm; /* revolutions/minute of drive */
extern int interleave; /* hardware sector interleave */
extern int trackskew; /* sector 0 skew, per track */
- --- 82,88 ----
***************
*** 212,218 ****
*/
if (fssize <= 0)
printf("preposterous size %d\n", fssize), exit(13);
! wtfs(fssize-1, DEV_BSIZE, (char *)&sblock);
/*
* collect and verify the sector and track info
*/
- --- 210,217 ----
*/
if (fssize <= 0)
printf("preposterous size %d\n", fssize), exit(13);
! /* the last block transfer must be in real sector size byte */
! wtfs(fssize-(realsectorsize/512), realsectorsize, (char *)&sblock);
/*
* collect and verify the sector and track info
*/
*** sbin.orig/newfs/newfs.c Wed Nov 20 11:18:55 1996
- --- sbin/newfs/newfs.c Wed Nov 20 11:24:39 1996
***************
*** 167,175 ****
int trackspares = -1; /* spare sectors per track */
int cylspares = -1; /* spare sectors per cylinder */
int sectorsize; /* bytes/sector */
- - #ifdef tahoe
int realsectorsize; /* bytes/sector in hardware */
- - #endif
int rpm; /* revolutions/minute of drive */
int interleave; /* hardware sector interleave */
int trackskew = -1; /* sector 0 skew, per track */
- --- 167,173 ----
***************
*** 530,540 ****
- --- 528,553 ----
fssize /= secperblk;
pp->p_size /= secperblk;
}
+ #else
+ realsectorsize = sectorsize;
+ if (sectorsize != DEV_BSIZE) { /* XXX */
+ int secperblk = sectorsize / DEV_BSIZE;
+
+ sectorsize = DEV_BSIZE;
+ nsectors *= secperblk;
+ nphyssectors *= secperblk;
+ secpercyl *= secperblk;
+ fssize *= secperblk;
+ pp->p_size *= secperblk;
+ }
#endif
mkfs(pp, special, fsi, fso);
#ifdef tahoe
if (realsectorsize != DEV_BSIZE)
pp->p_size *= DEV_BSIZE / realsectorsize;
+ #else
+ if (realsectorsize != DEV_BSIZE)
+ pp->p_size /= real
sectorsize/DEV_BSIZE;
#endif
if (!Nflag)
close(fso);
***************
*** 676,679 ****
fprintf(stderr, "\t-x spare sectors per cylinder\n");
exit(1);
}
- -
- --- 689,691 ----
------------------------------
End of hackers-digest V1 #1669
******************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611271443_MC1-BCB-65A2>