Re: CVS removal from the base

2011-12-04 Thread Bakul Shah
On Sun, 04 Dec 2011 16:42:04 PST Julian Elischer jul...@freebsd.org  wrote:
 On 12/4/11 3:36 PM, Randy Bush wrote:
 
  i suspect that my install pattern is similar to others
 o custom install so i can split filesystems the way i prefer,
   enabling net  ssh
 o pkg_add -r { bash, rsync, emacs-nox11 } (it's not a computer
   if it does not have emacs)
 o hack /etc/ssh/sshd_conf to allow root with password
 o rsync over ~root
 o hack /etc/ssh/sshd_conf to allow root only without-password
 o rsync over my standard /etc/foo (incl make.conf and src.conf)
   and other gunk
 o csup releng_X kernel, world, doc, ports
 o build and install kernel and world
 
  and then do whatever is special for this particular system.
 
  anything which would lessen/simplify the above would be much
  appreciated.  anything not totally obiously wonderful which would
  increase/complicate the above would not be appreciated.
 
 my suggestion is that the 'sysports' or 'foundation ports'  or
 'basic ports', (or whatever you want to call them) in their package
 form come with the standard install in fact I'd suggest that they
 get installed into some directory by default so that 'enabling' them
 ata later time doesn't even have to fetch them to do the pkg_add.
 
 They have pre-installed entries in /etc/defaults/rc.conf. and only 
 their rc,d
 files need to beinstalled into /etc along with their program files.
 They are as close to being as they are now with the exception of
 being installed in the final step instead of at the same time as the 
 rest of the stuff,
 and it allows them to easily be 'deinstalled' and replaced by newer 
 versions.
 
 Some of them would come from the current system sources and some of 
 them would be
 what are currently 'normal' ports but we consider them to be 'basic' 
 and 'extra supported'
 
 Examples of the first type would be bind, sendmail, cvs, and examples
 of the second type would be perl, bash, maybe python, and possibly a 
 very minimal set of the
 X11 packages.
 
 These are things we talk about having extra support for in the 
 installer anyhow.
 I also suggest that said packages include a plugin for 
 sysinstall/bsdinstall. so that it can ask its own
 quesitons during install.
 
A while back I had toyed with a config based approach. The
idea is you install a minimal system and then use one of the
predefined system configs to bring the system upto a desired
state.  The same config will use your local script of the same
name if one exists, to allow for local modifications.  The
same config (or an updated version) can be rerun after an
update.

Basically the idea is that you are dealing with a system as a
_whole_ for the purpose of install/update/convert/replicate.
You are capturing the personality or metadata of a system
a single file (it in turn relies on a small set of small text
files). This can be used for other purposes as well.

A config is essentially names of packages to install, variable
names, names of any pre/post external scripts to run, and
other included configs. But no executable logic here!

If this is used, a new release would also contain a repo for
every predefined script -- this makes it easy to see what
changed and deal with it.

Benefits:
- people can consistently customize their setup and keep
  it so after an upgrade
- what is included in the base system becomes largely
  irrelevant
- you can check/fix system personality at any time
- you can generate a local config easily
- can exactly replicate the same config on multiple machines
- can systematically change the personality of your system
- you can integrate this in sysinstall (and provide more
  flexibility)
- you can define your own specialized configs for whatever
  purpose.

To give you an idea:
syscfg install foo# install foo on a new installation
syscfg set foo# change existing (unconfigured) system to foo
syscfg convert bar# change existing (configured) system to bar
syscfg diff foo   # compare local system against foo
syscfg [-f] check   # check and optionally fix 
syscfg update

You would need to tell it where to get its data (either a
released ISO or a site). Lot of details would have to be
worked out.

Unfortunately I don't get to use FreeBSD much these days @
work and my home setup doesn't change much.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: No human readable message with g_vfs

2011-01-03 Thread Bakul Shah
On Mon, 03 Jan 2011 21:20:42 +0300 Anonymous swel...@gmail.com  wrote:
 
 Do you mean perror(1)?
 
   $ perror 5
   Input/output error

I prefer mine:

$ errno () { grep ^#.*\\$*\\ /usr/include/sys/errno.h }
$ errno 5
#define EIO 5   /* Input/output error */
$ errno EIO
#define EIO 5   /* Input/output error */
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: No human readable message with g_vfs

2011-01-03 Thread Bakul Shah
On Mon, 03 Jan 2011 22:21:51 +0300 Anonymous swel...@gmail.com  wrote:
 Bakul Shah ba...@bitblocks.com writes:
 
  On Mon, 03 Jan 2011 21:20:42 +0300 Anonymous swel...@gmail.com  wrote:
 =20
  Do you mean perror(1)?
 =20
$ perror 5
Input/output error
 
  I prefer mine:
 
  $ errno () { grep ^#.*\\$*\\ /usr/include/sys/errno.h }
  $ errno 5
  #define EIO 5   /* Input/output error */
  $ errno EIO
  #define EIO 5   /* Input/output error */
 
 perror(1) displays localized messages
 
   $ LANG=3Dja_JP.UTF-8 perror 5
   =E5=85=A5=E5=87=BA=E5=8A=9B=E3=82=A8=E3=83=A9=E3=83=BC=E3=81=A7=E3=81=99
 
   $ LANG=3Duk_UA.UTF-8 perror 5
   =D0=9F=D0=BE=D0=BC=D0=B8=D0=BB=D0=BA=D0=B0 =D0=B2=D0=B2=D0=BE=D0=B4=D1=83=
 -=D0=B2=D0=B8=D0=B2=D0=BE=D0=B4=D1=83

Yes, definitely useful. Perhaps strerror would be a better name?

 but I have to agree that knowing errno macro is useful

And you can use grep tricks :-)

$ errno '[dD]evice'
#define ENXIO   6   /* Device not configured */
#define ENOTBLK 15  /* Block device required */
#define EBUSY   16  /* Device busy */
#define EXDEV   18  /* Cross-device link */
#define ENODEV  19  /* Operation not supported by device */
#define ENOTTY  25  /* Inappropriate ioctl for device */
#define ENOSPC  28  /* No space left on device */
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: limits to memory on amd64

2010-11-09 Thread Bakul Shah
On Tue, 09 Nov 2010 08:45:14 PST Julian Elischer jul...@freebsd.org  wrote:
 During the discussion at MeetBSD the question came up as to what the real
 limiting factors were with regard to how much RAM a system could have.
 it was put to us that the limit was currently around 512 GB, though no-one
 at teh discussion knew what the mechanism of the limitation was or 
 what might ligh beyond it.
 
 Could anyone who knows, pipe upt and let use know what the factors are,
 and if the current limit is overcome, what the next one after that will be?

You mean beyond architectural limits?

From Wikipedia:

Larger physical address space: The original
implementation of the AMD64 architecture implemented
40-bit physical addresses and so could address up to 1 TB
(2^40 bytes) of RAM. Current implementations of the AMD64
architecture (starting from AMD 10h microarchitecture)
extend this to 48-bit physical addresses and therefore
can address up to 256 TB of RAM. The architecture permits
extending this to 52 bits in the future (limited by the
page table entry format); this would allow addressing of
up to 4 PB of RAM.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Interpreted language(s) in the base

2010-08-20 Thread Bakul Shah
On Thu, 19 Aug 2010 20:35:59 +0200 C. P. Ghost cpgh...@cordula.ws  wrote:
 
 But seriously, the point isn't so much which specific interpreter
 we use (if we go down this road), it's about libraries: most
 sysadmin tasks require some basic networking and I/O,
 and a FFI to seamlessly call out C functions from .so libs.
 
 And, of course, instead of writing 1,001 sysadmin scripts
 with endless code duplication and reinventing of the wheel,
 common sysadmin tasks should also be made into reusable
 functions, grouped into modules.

Exactly what I had in mind.

  And we don't have to argue about which language. I would
  suggest setting up a wiki page to list all the system scripts
  people want to write and get cracking in your favorite
  language! May the best effort win :-) At the very least we
  will get some useful tools out of this effort. =A0I will
  certainly help out with Scheme.
 
 Funny idea. I only hope we won't end up with a typical
 post-dot-com young developer distribution, a la:
 
   60% PHP (yuck!)
   25% Java (and XML-everywhere)
   15% ${OTHERS}
 
 ;-)

If that is what people want then so be it :-)

But I think only little languages like forth, lua, sh, rc,
es  scheme have small footprint interpreters that start up
fast and are reasonably efficient.

Anyway, system programming in Scheme is what interests me and
something I already tinker with on and off. If anyone is
interested (in helping or just playing with it), let me know
privately (but *not* on this mailing list).
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Interpreted language(s) in the base

2010-08-20 Thread Bakul Shah
On Fri, 20 Aug 2010 21:33:08 +0200 =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= 
d...@des.no  wrote:
 C. P. Ghost cpgh...@cordula.ws writes:
  After all LISP-like syntax is *still* more common and prevalent
  than Lua, e.g. in Elisp, guile, esh, scsh and a lot of other apps
  that use it as a small language. So we can expect more users
  to be at least partially familiar with it. And there *are* lightweight
  MIT- or BSD-licensed scheme interpreters out there too:
 
 Considering that the majority of people who might be interested in using
 this know *neither* Lisp *nor* Lua, my vote is for Lua, because people
 who are familiar with neither will be more open to learning Lua, which
 resembles other languages they already know, than Lisp, which doesn't.

[Couldn't resist responding but my last message on this tangent]
If you are open to learning a C like language, one can
provide a C like frontend syntax to most of Scheme  to a
degreee similar to lua.  Like C/Lua etc. Scheme is also a
block structured language.  Apart from syntax, the key
differences are:

- everything is an expression.
- variables are not typed (anything can be assigned to a var)
- functions can be anonymous, nested and returned from other functions
- symbols  lists are built-in unlike in C
- no built-in structs, unions or ptrs
- a very powerful macro facility
- support for continuations

ksm for instance implements a C like syntax.

See http://square.umin.ac.jp/hchang/ksm/ref/ksm_13.html

[Yes, I am aware of Dylan and what happened to it but still
 think this can be a useful effort]
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Interpreted language(s) in the base

2010-08-19 Thread Bakul Shah
On Thu, 19 Aug 2010 18:00:54 +0200 C. P. Ghost cpgh...@cordula.ws  wrote:
 On Wed, Aug 18, 2010 at 3:43 PM, Andrew Reilly arei...@bigpond.net.au wro=
 te:
  On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote:
  got any other suggestions?
 
  This is very much a sorry I asked question, but is none-the
  less quite a good one, given the size of the hole to be plugged.
 
  I think that a reasonable answer for this sort of thing might be
  one of the dynamic languages that compiles to C, like (perhaps)
  one of the schemes (chicken, gambit-C, bigloo, etc). =A0You get
  the benefit of flexibility and dynamism with good regexp and
  data structure ability, good performance, and only requiring the
  build tools available in the base system, as long as you don't
  want to be the developer: just ship the C code (as well as the
  source, of course).
 
  Unfortunately it seems that quite a lot of people have issues
  with lisp syntax these days.
 
 +1 for a scheme shell, but not for the heavy-weight variety that
 compiles to C, as that would tie them to a subset of ${ARCH}es.

+1 for Scheme! It has a lot in its favor (see below).

But this is an abstract discussion. Until there are plenty of
useful system scripts (in one of these languages) that people
really want, nothing is going to change.

There is no reason to wait until something is in the base.
And we don't have to argue about which language. I would
suggest setting up a wiki page to list all the system scripts
people want to write and get cracking in your favorite
language! May the best effort win :-) At the very least we
will get some useful tools out of this effort.  I will
certainly help out with Scheme.

-- bakul

Scheme has many interpreters  compilers so you can write
Scheme scripts to be interpreted and at some point compile
them for better performance if necessary. Scheme has some
excellent text books, a precise definition for a given
standard, it changes slowly, has IDEs and so on. If you stick
to the R4RS subset, almost every scheme interprpter/compiler
will handle it.  It has a very powerful macro facility.  Its
interpreters can be very small. s9fes and tinyscheme for
example are about 5K lines of C code each.  Stalin compiles
Scheme to some extremely tight C code by doing global program
analysis.  And there are many other systems in between.  slib
is a library of a lot of useful packages that can be used
with most Schemes.  Many of these interpreters can be used
from C/C++.  Many provide a C-FFI to call C functions.
Tinyscheme packages all of Scheme state in a single structure
so one can easily create a separate Scheme interpreter per
thread.  There is even a vi clone written in 4K lines s9fes
Scheme!  Still beta but already useful.

These many choices can be very confusing but we can pick one
and stick to writing R4RS portable Scheme code.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: bsdgrep does not work with tail -f | grep combination

2010-08-04 Thread Bakul Shah
On Tue, 03 Aug 2010 20:21:56 +0200 Gabor Kovesdan ga...@freebsd.org  wrote:
 Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
  Hi,
 
  It seems bsdgrep does not work when piped from tail -f.
  I'm running r210728.
 
  term0$ jot 10  /tmp/1
  term0$ tail -f /tmp/1 | grep 0
  [no output]
 
  otherterm$ jot 10  /tmp/1
  [no output to term0]
 
  =
 
  with GNU grep:
 
  term0$ tail -f /tmp/1 | gnugrep 0
  10
  otherterm$ jot 10  /tmp/1
  [on term0]
  10
  10
 
 I've checked on 8.0 and GNU grep doesn't output anything either for me. 
 If you use tail -f, you will enter more lines and end it with EOF, won't 
 you? And then BSD grep will process the input and print out matches. I 
 don't think it's bad behaviour in itself but if you can explain why you 
 think it's bad I'm willing to change it.

This is more fundamental, not just limited to grep.  tail -f
never closes its stdout channel so the next process in the
pipeline will never seen an EOF on its stdin and must
continue processing its input. Try this:

rm -f /tmp/1; touch /tmp/1
tail -f /tmp/1 | cat 
while sleep 1; do date  /tmp/1; done

Notice how cat doesn't quit. In fact

tail -f /tmp/1 | bsdgrep ''

must behave exactly the same as 

tail -f /tmp/1 | cat

and so must this:

tail -f /tmp/1 | cat | bsdgrep ''

bsdgrep when used this way doesn't quit but doesn't do
anything either (including printing what tail -f spits out
from existing file data). This is just a bug.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Importing clang/LLVM into FreeBSD HEAD

2010-05-31 Thread Bakul Shah
On Mon, 31 May 2010 09:52:48 +0200 Roman Divacky rdiva...@freebsd.org  wrote:
 
 I would like to propose to integrate clang/LLVM into FreeBSD HEAD
 in the near future (days, not weeks).
 
 clang/LLVM is a C/C++/ObjC compiler (framework) which aims to possibly
 replace gcc. It is BSDL-like licensed. The sources are ~45MB (the
 svn checkout is 97MB). Clang/LLVM is written in C++.
 
 Clang can compile all of FreeBSD on i386/amd64 including world and booting
 kernel. Other architectures that are close to working are MIPS, PowerPC
 and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM
 sources and the build infrastructure and this is what we aim to integrate
 at first.

 The import of clang/LLVM was discussed at the toolchain summit May 10th
 but I would like to hear your opinion. I got approval from core@ on
 importing it.
 
 So please share your support or resistance to the idea of importing clang.
 
 Roman Divacky

I already use clang for some things but I think the issue
here is not support/resistance but something else:

* IMHO for a change of this nature the core needs to publish
  a set of clear acceptance criteria for importing clang.
  Can this be done?

* Since clang doesn't support all the archs, what is the plan
  for unsupported archs?
  a. Is FreeBSD going to have both compilers in the base?
  b. Is the project drop these FreeBSD ports? or
  c. Do people have to import gcc from ports to build these
 FreeBSD ports?

* What about ports?

* Basically the core needs to lay out a roadmap.

It is clear that not everyone has the same view of what the
acceptance criteria might be so publishing it would help
people understand what to expect.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Importing clang/LLVM into FreeBSD HEAD

2010-05-31 Thread Bakul Shah
On Mon, 31 May 2010 12:33:18 MDT M. Warner Losh i...@bsdimp.com  wrote:
 
 :  It is clear that not everyone has the same view of what the
 :  acceptance criteria might be so publishing it would help
 :  people understand what to expect.
 : 
 : nothing changes for the ports, there's an ongoing project to enable
 : ports to be usable with clang (or some other compiler) but thats
 : orthogonal to this.
 
 Part of the problem with this thread is that the whole, agreed plan
 wasn't laid out at the first part of it, so people are freaking out
 about what the plans are for the future.  They were discussed and
 first order agreement was reached at the tool chains summit.  But part
 of the agreement was to post the whole agreement so people know and
 understand the various trade offs.
 
 I think that would go a long way towards answering the questions that
 are being raised and to quell the visceral reaction that I've seen in
 this thread

Exactly!

I still urge core to lay out a clear plan. And don't forget
to indicate the acceptance criteria to be met for each step!
[Not to add bureaucracy but to ensure that nothing falls
through the cracks]

Can't speak for others but I am very appreciative of all the
work put in enthusiastically by Roman and others to get clang
into FreeBSD. Exciting to have a real alternative to gcc!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: swapon vs savecore dilemma

2003-09-02 Thread Bakul Shah
  Is fsck really that memory heavy so that it needs swap?
 
 Yes, if you have a huge FS.
 
 The problem is that the checking of the CG bitmaps during an fsck
 require that you have all the bitmaps in core

Hmm
For a one TB FS with 8KB block size you need 2^(40-13) bits
to keep track of blocks.  That is 2^24 bytes or 16Mbytes.
That doesn't seem so bad (considering that you really should
have a lot more RAM if you are playing terrybytes of data).

 My suggestion (which has been my suggestion all along) is to add
 two date stamped CG bitmap bitmaps somewhere (my favorite place
 for this is to steal space at the front of inode 1, which is used
 only rarely, since people don't use the whiteout feature, and
 which can be made compatible with whiteouts, in any case).

This is the old stable storage idea.  You need a generation
number rather than a date stamp but the idea is the same.
Something needs to be done so that time to fsck depends on
the outstanding FS traffic at the time of the crash rather
than the size of the FS (especially when you are dealing with
multi terabytes of data).
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Anyone working on fsck?

2003-03-17 Thread Bakul Shah
UFS is the real problem here, not fsck.  Its tradeoffs for
improving normal access latencies may have been right in the
past but not for modern big disks.  The seek time  RPM have
not improved very much in the past 20 years while disk
capacity has increased by a factor of about 20,000 (and GB/$
even more).  IMHO there is not much you can do at the fsck
level -- you stil have to visit all the cyl groups and what
not.  Even a factor of 10 improvement in fsck means 36
minutes which is far too long.  Keeping track of 67M to 132M
blocks and (assuming avg file size of 8k to 16k) something
like 60M to 80M files takes quite a bit of time when you are
also seeking all over the disk.

A few ideas:

When you have about 67M (2^26) files, ideally you want to
*avoid* checking as many as you can.  Given access times, you
are only going to be able to do a few hundred disk accesses
at most in a minute.  So you are going to have only a few
files/dirs that may be inconsistent in case of a crash.  Why
not keep track of that somehow?

If you need about 1GB of space to store the state of a TB
file system that needs to be checked, may be it _should_ be
*stored* in a contiguous area on the FS itself.  1GB is about
0.1% of space.

Typically only a few cyl grps may be inconsistent in case of
a crash.  May be some info about which cyl groups need to be
checked can be stored so that brute force checking of all
grps can be avoided.

Typically a file will be stored in one or a small number of
cyl groups.  If that info. is stored somewhere it can speed
things up.

Extant based allocation will reduce the number of indirect
blocks.  But may be this is not such a big issue if most of
your files fit in a few blocks.

Anyway, support for all of these have to be done in the
filesystem first before fsck can benefit.

If instead you spend time optimizing just fsck, you will
likely make it far more complex (and potentially harder to
get right).

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


Re: Anyone working on fsck?

2003-03-17 Thread Bakul Shah
 Now, before we go off and design YABFS, can we just get real for
 a second ?

I leave it to others to design YAFS, I just wanted to
complain about this one :-)  Every few years I seriously look
at speeding up fsck but give up.  I remember even asking
about it a few years ago on one of these groups.

 I have been tending UNIX computers of all sorts for many years and
 there is one bit of wisdom that has yet to fail me:
 
   Every now and then, boot in single-user and run full fsck
   on all filesystems.
 
 If this had failed to be productive, I would have given up the
 habit years ago, but it is still a good idea it seems.

Even now I use fsck in forground since the background fsck
was not stable enough the last time I used it.  But I
remember thinking fsck was taking too long for as long as I
have used it (since 1981).

 Personally, I think background-fsck is close to the ideal situation
 since I can skip the boot in single-user part of the above
 profylactic.

Anything that runs for half hour or more in fg is likely to
take longer in bg.  What happens if the system crashes again
before it finishes?  Will bg fsck handle that?  Am I right in
thinking that it can not save files in /lost+found?

In general I am very uneasy with bg fsck -- when I am validating
something I don't want to be creating new stuff.

 If you start to implement any sort of journaling (that is what you
 talked about in your email), you might as well just stop right at
 the clean bit, and avoid the complexity.

No, I didn't suggest journaling, I suggested storing all
state in a contiguous area (or a small number of such areas).
indirect blocks, keeping track of free blocks, etc.  You can
still do a completely exhaustive fsck but it won't be
exhausting to you.

Journaling is also a good idea:-)

 Optimizing fsck is a valid project, I just wish it would be somebody
 who would also finish the last 30% who would do it.

I am skeptical you will get more than a factor of 2
improvement without changing the FS (but hey, that is 3 hours
for Julian so I am sure he will be happy with that!).

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


Re: Anyone working on fsck?

2003-03-17 Thread Bakul Shah
 You talk like I have a choice :-)
 I cannot change ufs/ffs and even if I could the clients wouldn't go for
 it.

What about changing the size of block size or cyl grp size?
Do they change things much?

 The problem space is
 
 Fsck of UFS/FFS partitions is too slow for 200GB+ filesystems.

 The solution space can not contain any answer that includes redefining
 UFS/FFS. Welcome to the real world. :-)

I am so glad I have a separate machine for every few GB of
disk space :-)

So may be you can have on a multi-processor solution.  I'll
try to come up with more useful suggestions given your
constraints

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


Re: Anyone working on fsck?

2003-03-17 Thread Bakul Shah
  UFS is the real problem here, not fsck.  Its tradeoffs for
  improving normal access latencies may have been right in the
  past but not for modern big disks.
...
 Sorry, but the track-to-track seek latency optimizations you
 are referring to are turned off, given the newfs defaults, and
 have been for a very long time.

I was thinking of the basic idea of cylinder groups as good
for normal load, not so good for fsck when you have too many
CGs. I wasn't thinking of what fsck does or does not do.

 Basically, the problem is that for a BG fsck, it's not possible
 to lock access on a cylinder group basis, and then there is a hell
 of a lot of data on that drive.

Note that Julian said 6 hours to fsck a TB in the normal
foreground mode.

 What Julian needs is a Journalling or Log-structured FS.  

All that Julian wants is a faster fsck without mucking with
the FS!

While I agree with you that you do need a full consistency
check, it is worth thinking about how one can avoid that
whenever possible.  For example, if you can know where the
disk head is at the time of crash (based on what blocks were
being written) it should be possible to avoid a full check.

 The easiest way to do this is to provide some sort of domain
 control, so that you limit the files you have to check to a
 smaller set of files per CG, so that you don't have to check
 all the files to check a particular CG -- and then preload the
 CG's for the sets of files you *do* have to check.

If you have to visit a CG (during fsck) you have already paid
the cost of the seek and rotational latency.  Journalling
wouldn't help here if you still have a zillion CGs.

 Another way of saying this is... don't put all your space in a
 single FS.  8-).

Or in effect treat each CG (or a group of CGs) as a self
contained filesystem (for the purpose of physical allocation)
and maintain explicit import/export lists for files that span
them.

 The problem with having to (effectively) read every inode and
 direct block on the disk is really insurmountable, I think.

That is why I was suggesting putting them in one (or small
number of) contiguous area(s).  On a modern ATA100 or better
disk you can read a GB in under a minute.  Once the data is
in-core you can divide up the checking to multiple
processors.  This is sort of like a distributed graph
collection: you only need to worry about graphs that cross a
node boundary.  Most structures wille contained in one node.

Even for UFS it is probably worth dividing fsck in two or
more processes, one doing IO, one or more doing computation.

  Typically only a few cyl grps may be inconsistent in case of
  a crash.  May be some info about which cyl groups need to be
  checked can be stored so that brute force checking of all
  grps can be avoided.
 
 This would work well... under laboratory test conditions.  In
 the field, if the machine has a more general workload (or even
 a heterogeneous workload, but with a hell of a lot of files,
 like a big mail server), this falls down, as the number of bits
 marking unupdated cylinder groups becomes large.

Possible -- it is one of the ideas I can think of.  I'd have
to actually model it or simulate it beyond handwaving to know
one way or other.  May be useful in conjunction with other
ideas.

 ...AND... The problem is still that you must scan everything on
 the disk (practically) to identify the inode or indirect block
 that references the block on the cylinder roup in question, and
 THAT's the problem.  If you knew a small set of CG's, that needed
 checked, vs. all of them, it would *still* bust the cache, which
 is what takes all the time.


 Assume, on average, each file goes into indirect blocks.

On my machine the average file size is 21KB (averaged over
4,000,000 files).  Even with 8KB blocksize very few will have
indirect blocks.  I don't know how typical my file size
distribution is but I suspect the average case is probably
smaller files (I store lots of datasheets, manuals,
databases, PDFs, MP3s, cvs repositories, compressed tars of
old stuff).

But in any case wouldn't going forward from inodes make more
sense?  This is like a standard tracing garbage collection
algorithm.  Blocks that are not reachable are free.  Even for
a 1 TB system with 8K blocks you need 2^(40-13-3) == 16Mbytes
bitmap or some multiple if you want more than 1 bit of state.

 The problem is reverse mapping a bit in a CG bitmap to the file
 that reference it... 8^p.

Why would you want to do that?!

 Multithreading fsck would be an incredibly bad idea.

It depends on the actual algorithm.

 Personally, I recommend using a different FS, if you are going
 to create a honing big FS as a single partition.  8-(.

There are other issues with smaller partitions.  I'd rather
have a single logical file system where all the space can be
used.  If physically it is implemented as a number of smaller
systems that is okay.  Also note that now people can create
big honking files with video streaming at the 

Re: Problems with Current XFree86

2003-02-10 Thread Bakul Shah
 Since it works with 4.7-STABLE it must(?) be a current problem
 more than a XFree86 problem. Or?

I had the same problem -- something to do with files left
over from the original 4.7 installation.  Cured by
deinstalling XFree86-* ports, renaming /usr/X11R6 to
something else (in case something was needed), and then
reinstalling everything.  Thanks to portupgrade this was
pretty easy.  I reused the old XF86Config.

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



Re: rand() is broken

2003-02-02 Thread Bakul Shah
 Good point. We can re-implement random() internally with arc4rand().
 
 Objections?

Guys, please realize that random() is also used in generating
simulation inputs (or timing or whatever).  If you go change
the underlying algorithm or its parameters one can't generate
the same sequence from the same seed when repeating a test.
Some chip bug symptoms show up after hours/days of simulation
time and only with specific inputs so repeatablity is a
requirement.

The old 16 bit rand() was broken enough that it didn't matter
much (read: _I_ don't care) if its behavior got changed but
random() has a pretty long cycle and enough randomness to
be very useful and it *is* used.

*Please* don't change random() -- if you do that you will
break existing tests.  It is not a matter of just rewriting
tests since there is no easy way to predict  which input
triggers a certain bug -- one can try to use the same
binaries but that prevents fixing of bugs in the test
generation code itself.

If you think random() is not random enough for your purposes,
go create a new function with a *new* name.

[I see from his latest email that PHK remembered the old
discussion!]

-- bakul

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



Re: rand() is broken

2003-02-02 Thread Bakul Shah
 As I said, I don't know how big a concern this is.  But last time
 it was enough of a concern to make us keep rand() as it was.

[I know you are talking about rand() but Mark Murray's
earlier email about wanting to re-implement random() really
concerned me so I want to make sure my point gets across]

Not changing random() was of real concern to me when I was
doing chip simulations.  ASIC design verification folks won't
be happy if the rug is pulled out from under them.  In
general crypto and simulation needs are different and I don't
trust the crypto guys to look out for the simulation guys!

I don't care any more if rand() is changed but _please_ leave
random() alone!  And it would be nice to indicate *why* in
the source code for the next time this discussion comes up.

Thanks!

-- bakul

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



Re: rand() is broken

2003-02-02 Thread Bakul Shah
 RC4 is _utterly_ repeatable, given a particular seed/key.

May be but it is not the same as the current random().  Also,
I know you will want to change it the next time some one
points out a problem with RC4.

 Yes. And it breaks, and we have a complainant.

So create a new function!  Or use a different function to
generate or initialize the seed.  I think one has to treat a
behavior bug very carefully.  If enough people are depending
on it, it pretty much has to get enshrined as part of the
spec -- sort of like the timeout arg to select(). 

 The random() function in libc is documented to give the same
 pseudo-random output for a particular seed. if you link your
 program against a _different_ libc, you cannot expect your
 results to follow a particular number sequence.

There is an expectation that on subsequent releases of the
same OS things continue to work.

Historically rand() and random() under unix have been used
the most for simulation.  [aside: Earl T. Cohen (the author
of random(3)) also has had a lot to do in this area]

Why not totally separate all uses of crypto related random
number generator uses from the traditional simulation use?
That way you can change crypto_random to your heart's content
as the crypto needs change (as they will).

-- bakul

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



Re: rand() is broken

2003-02-02 Thread Bakul Shah
 Maybe I missed something, but why cannot you just rip random() from libc, 
 rename it to bakul_shah_random() and use that in your testing code?  Then you
 are safe from any changes to random(), and indeed have a portable RNG if your
 host OS changes.

Yes, *I* can do it but I don't work at every place they do
simulation!  If in the extreme you are suggesting that a
portable application shouldn't rely on any OS features, you
are of course right but that kind of makes mockery of any
claims of compatibility.  The point of compatibility is to
not break interfaces unless there is a significant benefit.

-- bakul

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



Re: rand() is broken

2003-02-02 Thread Bakul Shah
 a restriction on the OS.  If FreeBSD makes random2() using RC4 to avoid 
 changing rand() or random(), will people then start relying on random2()'s 
 behaviour, and when someone finds a problem in RC4, then the next will be 
 random3()?

What I am suggesting is to leave random() as it is and
guarantee its behavior won't change and add cryto_random() or
whatever, and indicate it *may* change.

 Would you have a problem with changes in the TCP/IP stack changing the 
 content of packets sent out when you connect(), if it breaks your TCP/IP 
 simulations?

This is not a similar situation.

Note that it is rand() that is broken, not random() as can be
seen by modifying Kris Kennaways' test so I don't see why
Mark Murray was talking about changing it in the first place.

#include stdlib.h
#include stdio.h

int main() {
int i;

for(i = 1; i = 1000; i++) {
srandom(i);
printf(%d: %d\n, i, random());
}
}

1: 1804289383
2: 1505335290
3: 1205554746
4: 1968078301
5: 590011675
6: 290852541
7: 1045618677
8: 757547896
9: 54915
10: 1215069295
11: 1989311423
12: 1687063760
13: 1358590890
14: 2146406683
15: 762299093
16: 462648444
17: 1227918265
...

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



Re: rand() is broken

2003-02-02 Thread Bakul Shah
 Would you prefer that we defined random() as
 
 int
 random(void)
 {
   static int retval = 0;
 
   return retval++;
 }

No because that would be a change from the exisiting random()
behavior :-)

As I indicated in my earlier email random() is not broken,
srand() is (as corrected by Andrey Chernov) so you won't be
fixing any bugs by changing random().  If you guys had left
the original rand() alone we wouldn't be discussing any of
this

random(3) also provides an initstate() call which presumably
allows you to change the amount of randomnes.  So here is
another suggestion: why not fold your algorithm change in
that function?  For example,

initstate(seed, RC4, 3);

changes the algorithm to RC4.  Yes, this is a change in the
interface but one I am sure most people can live with.

  There is an expectation that on subsequent releases of the
  same OS things continue to work.
 
 Where is that expectation guaranteed?
 Where is that expectation supported?

This expectation is a reasonable one.  Most commerical OSes
do a good job of maintaining compatibility.  IRIX certainly
did a pretty good job of it.  FreeBSD also does a pretty good
job on the whole.

 The two are related topics.

Yes, but not the same.

 Consider the (joking reference to) elephant-free biology. :-)

The way things are going we will be there pretty soon :-(

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



Re: rand() is broken

2003-02-02 Thread Bakul Shah
 Since you keep talking about random(), I must conclude you're
 knee-jerking, since we're not discussing that function.  Please stay
 on-topic :-)

Read through the thread.  In particular see Mark's message
[EMAIL PROTECTED] where he
says

Good point. We can re-implement random() internally with arc4rand().

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



Re: rand() is broken

2003-02-02 Thread Bakul Shah
  another suggestion: why not fold your algorithm change in
  that function?  For example,
  
  initstate(seed, RC4, 3);
  
  changes the algorithm to RC4.  Yes, this is a change in the
  interface but one I am sure most people can live with.
 
 No. Evil interface change. #ifdef hell while programs try to
 figure out OS differences.

How so?  This or a similar change is upward compatible in
that the existing behavior is left unchanged and it gives you
a way to replace the algorithm.

The basic issue is just what is the expected and (implicitly)
promised behavior of random().

AFAIK all random(3) implementations in various versions of
Unix come from Earl's original 4.2BSD implementation so in my
view the _expected_ behavior is to see the _exact_ same
sequence starting from a given seed.  This function is called
random() but it is equivalent to a mathematical function
which must provide the same sequence for the exact same
input.

You and a number of other people are saying that the exact
sequence is *not* promised so you are free to change the
algortithm as long as the statistical distribution is
uniform.

Earl chose to name his new implementation random() [even
though clearly he was replacing rand(3)] probably to not
break any existing scripts.  In my view any further behavior
change should either use a new name or make an upward
compatible change.

Now the question is whether perl uses system provided
random() or rand() or its own since perl is used extensively
in ASIC verification.

Any way, this is my last email on this subject since neither
one of us is convincing the other.

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



Re: rand() is broken

2003-02-02 Thread Bakul Shah
 Last 10 digits.
 
  FreeBSD   Redhat   SunOS 
 660787754660787754645318364
 3275486913275486911583150371
 2009993994   2009993994   715222008
 1653966416   1653966416   1349166998
 1074113008   1074113008   566227131
 2142626740   2142626740   1382825076
 1517775852   1517775852   583981903
 1453318125   1453318125   1453942393
 6196078076196078071952958724
 1999863931999863931599163286

Interesting  The SunOS output exactly matches random(3)
behavior from 4.3BSD!  In fact random() remained the same for
4.3BSD-Reno, -Tahoe, 4.4BSD-Alpha and Net2.

4.2BSD random() behavior is different from all of the above.
There was real bug-fix between 4.2BSD and 4.3BSD.

I don't know when the FreeBSD/Redhat change was made or if it
broke any statistical properties.

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



Re: rand() is broken

2003-02-02 Thread Bakul Shah
 Interesting  The SunOS output exactly matches random(3)
 behavior from 4.3BSD!  In fact random() remained the same for
 4.3BSD-Reno, -Tahoe, 4.4BSD-Alpha and Net2.
 
 4.2BSD random() behavior is different from all of the above.
 There was real bug-fix between 4.2BSD and 4.3BSD.
 
 I don't know when the FreeBSD/Redhat change was made or if it
 broke any statistical properties.

FYI:
The FreeBSD change was made in -r1.4 of random.c by Andrey in
Oct 1996.  The previous version of random.c behaves exactly
the same as the one in  4.3BSD, SunOS and AIX.  I am sorry I
was too busy with other things then and missed this change.

Andrey refers to an OCT 1988 CACM paper by Park  Miller
Random number generators: good ones are hard to find as a
justification for this change.

Also FYI: NetBSD random(3) matches the 4.3BSD random().
Haven't checked OpenBSD.

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



Re: Style fixups for proc.h

2003-02-01 Thread Bakul Shah
 Julian Elischer writes:
  I don't know about the protection with a '_'.
  
  It's not standard and usually the name matches that used in the actual
  function.
 
 When the prototype parameter name matches a local variable, the C compiler
 (and lint) whine about clashes between names in local/global namespace.

According to C99, a function prototype has its own scope or
name space.  It terminates at the end of the function
declarator.  Basically naming a parameter in a function
prototype is an aide to the human user; it is not needed for
correct compilation[1] so this warning is bogus.  As the
spec says in section 6.7.5.3 (according the draft I have)

The identifiers [naming parameters] are declared for
descriptive purposes only and go out of scope at the end
of the [prototype] declaration.

I can't see what actual error is avoided by this warning.

 2 ways to fix this are to protect the prototype argument names with the
 _, or to remove the argument name altogether.

Why not fix the compiler  lint instead of cluttering up
declarations?

-- bakul

[1] Except for what is needed for declaring flexible or
variable length array parameters.

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



Re: Style fixups for proc.h

2003-02-01 Thread Bakul Shah
  I can't see what actual error is avoided by this warning.

s/actual/potential/

 
 If a named prototype clashes with something in global scope,
 isn't it still a shadowing issue?  They should probably never
 be *in* scope.

Nothing is being shadowed.  Paramater names in a function
prototype (as opposed to a function definition) are simply
not relevant to the compiler (their distinctness, type and
positions are but not the actual names).  No potential bug is
being hidden by saying, for example,

int x;
int foo(int x);

It is perfectly fine to later define foo as

int foo(int y)
{
return x + y;
}

The compiler should simply discard any parameter names in a
prototype once the prototype is digested and C programmers
need to know that.  Now if parameter y shadows a global y one
may want to be warned about it.

Garrett gives an example:

 Say you have an object and a function declared in global scope:
 
   int foo;
   /* many lines of declarations */
   /* perhaps this is even in a different file */
   void bar(quux_t foo);
 
 At some point, somebody changes the spelling of `foo' and adds a
 preprocessor macro for compatibility:
 
   union baz {
   int foo;
   struct frotz *gorp;
   } foobaz;
   #define foo foobaz.foo
 
 What happens to the declaration of that function?  Well,
 
   void bar(quux_t foobaz.foo);
 
 is a syntax error.

This sort of problem can occur when you have any two objects named the
same.  Consider:

struct dumb { int foo; };

After the above redefinition this defn won't compile (even
after his amendation:-).

Not naming parameters is one solution but with some loss of
perspicuity.  Consider:

int* make_matrix(int, int);
versus
int* make_matrix(int rows, int columns);

-- bakul

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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Bakul Shah
  Until pppd is taught to create the interface if one doesn't
  exist, this information needs to be in /usr/src/UPDATING.
 
 pppd doesn't need to be taught to create the interface.  Rather it needed
 to learn to check for ppp support in a non-stupid way.  The following
 patch should do it as well as making pppd do the right thing when
 support isn't compiled in, but a module is available.  It should make
 things work with a GENERIC kernel.

`device ppp' was already defined in my kernel config file so
there was no need to kldload if_ppp.  But I had to run
`ifconfig create ppp' to make things work.

I don't much like auto kldloading modules from suid programs.
A simple hack is to just add ifconfig create ppp in rc.local.
Also kldload if_ppp if needed.

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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Bakul Shah
 Here's a new patch that gives the user more of a hint at how to add PPP
 support and only loads the module if they are actully root.  How's this
 look?

I still don't like it.  How to explain

I don't think it is pppd's responsibility to muck with
modules.  It is like mount kldloading a disk driver module.
Neither program has any business guessing which module name
goes with which device/feature.

What if I want to run ppp over ethernet over atm?  I know you
can't do this today but in general the trend should be to
make protocol modules more flexible not less.  Hardwiring
module names is analogous to making a function non-reentrant.

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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Bakul Shah
 Brooks Davis wrote:
  This isn't going to have an effect on the ability to use kernel ppp for
  other things.  The tty orientation of pppd and the outdated, unmodular
  design on ppp(4) have taken care of that.  This patch gives people
  the functionality they want (pppd just working) without any major
  entanglements (the whole function is 20 lines).

I meant reuse of pppd.  From what I remember, pppd does a lot
of the control plane stuff (IPCP, CHAP...) which is useful
for other ppp-over-foo combinations.  In general a different
module or set of modules may implement ppp-over-foo so
hardwiring the module name in pppd is not a good idea.  Now
you are probably thinking: In that case why not just default
to if_ppp and otherwise use an environment variable?.  This
would add complexity and another potential security hole.

If someone
  wants to make pppd work on arbitrary devices we can deal with that when
  it happens and I frankly doubt it's ever going to since we've got
  netgraph to do that with.

Existance of an alternative is not an argument in favor of
allowing something to rot since doing so limits your flexibility.

Terry writes:
 Depending on the value of sysctl kern.module_path, if the if_ppp
 module does not exist, and one of the path components is writeable,
 then this would permit you to abuse the pppd to load arbitrary modules
 into the kernel.

Thank you for explicating the security argument!  I'll also
point out that hardwiring module names makes it harder to
experiment with replacement modules (i.e. I may want to
develop if_super_duper_ppp).

 But by the same token, mount and ifconfig have the same problems;
 on the other hand, unlike pppd, they are not suid root.

AFAIK mount does no autoloading (i was using it as another
place where one might be tempted to use autoloading).  In
general any tool (command) that relies on a resource or
feature can have the same problem of the resource not
existing.  Just how far does one go to discover/autoload
resources?  Should we try to fetch it from a trusted
repository?  Should we try to compile it if we have the
sources?  It is a slipper slope.  A new programmer next year
will assume all the old programmers were fools and to him it
will be obvious the module sources fetched afresh and
compiled.  Okay, I am exaggerating.

 On general principles, loading modules with commands, rather than the
 kernel doing it automatically, is a bad idea.  But FreeBSD already
 does this in a number of commands, because it lacks a certralized
 feature demand support facility.

Another area for endless debating:-)  But don't worry, I'll stop soon!

If only the kernel is allowed to load them on demand, there
needs to be a way for modules to declare the feature-set they
provide and for the kernel to follow administrative policies
while autoloading them.

 You could also make security arguments on the basis of what if the
 administrator didn't want the machine to be able to be configured
 for PPP -- on purpose?

This is a policy argument.  Thanks for bringing that up!

 As it is, this patch does nothing worse than add to an existing
 mess brought about by not having an integrated demand-load facility;
 I don't see this as a problem... if there;s a problem, fix it first
 in mount and ifconfig, before you complain about this patch.

It adds needless complexity.  In any case, complain is too
strong a word!  I just pointed out something that I didn't
like based on the principles I try to follow when writing
software.  Consider it in the leading a horse to water
category:-)  If the horse thinks it is just a mirage, that
too is fine with me!  We can argue about that too. ducks

I have used up my 2 cents many times over, so over and out!

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



Re: pppd not working on latest current 2002-10-20

2002-10-25 Thread Bakul Shah
 On Fri, Oct 25, 2002 at 06:15:55PM +, Dave Evans wrote:
  Is anyone using pppd on CURRENT.  somewhere between may and October it
  seems to have broken.  My KERNEL is GENERIC, my sources are dated cvs
  -D2002-10-20, but I now get a message about needing facilities in the
  kernel. However, the kernel has many ppp entry points, I haven't
  modified GENERIC which loads the ppp device, I've tried loading modules
  with ppp in their name all to no avail.
 
 You need to create an interface first. Run ifconfig ppp create.

Until pppd is taught to create the interface if one doesn't
exist, this information needs to be in /usr/src/UPDATING.

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



ldconfig in /etc/rc /etc/rc.d/ldconfig

2002-09-22 Thread Bakul Shah

If the ldconfig_insecure flag is set in /etc/rc.conf,
ldconfig doesn't do anything useful at startup time except
complain.  The following patch should fix it.

diff -ur /usr/src/etc/rc ./rc
--- /usr/src/etc/rc Tue Sep 17 21:02:01 2002
+++ ./rcSun Sep 22 16:49:19 2002
@@ -692,9 +692,10 @@
 # add your own entries or you may come to grief.
 #
 ldconfig=/sbin/ldconfig
+ldc_flags=
 case ${ldconfig_insecure} in
 [Yy][Ee][Ss])
-   ldconfig=${ldconfig} -i
+   ldc_flags=-i
;;
 esac
 if [ -x /sbin/ldconfig ]; then
@@ -705,7 +706,7 @@
fi
done
echo 'ELF ldconfig path:' ${_LDC}
-   ${ldconfig} ${_LDC}
+   ${ldconfig} ${ldc_flags} ${_LDC}
 
# Legacy aout support for i386 only
case `sysctl -n hw.machine_arch` in
@@ -719,7 +720,7 @@
fi
done
echo 'a.out ldconfig path:' ${_LDC}
-   ${ldconfig} -aout ${_LDC}
+   ${ldconfig} -aout ${ldc_flags} ${_LDC}
;;
esac
 fi
diff -ur /usr/src/etc/rc.d/ldconfig ./rc.d/ldconfig
--- /usr/src/etc/rc.d/ldconfig  Tue Sep 17 21:02:03 2002
+++ ./rc.d/ldconfig Sun Sep 22 16:48:12 2002
@@ -21,7 +21,8 @@
case ${OSTYPE} in
FreeBSD)
ldconfig=${ldconfig_command}
-   checkyesno ldconfig_insecure  ldconfig=${ldconfig} -i
+   ldc_flags=
+   checkyesno ldconfig_insecure  ldc_flags=-i
if [ -x ${ldconfig_command} ]; then
_LDC=/usr/lib
for i in ${ldconfig_paths}; do
@@ -30,7 +31,7 @@
fi
done
echo 'ELF ldconfig path:' ${_LDC}
-   ${ldconfig} -elf ${_LDC}
+   ${ldconfig} -elf ${ldc_flags} ${_LDC}
 
# Legacy aout support for i386 only
case `sysctl -n hw.machine_arch` in
@@ -44,7 +45,7 @@
fi
done
echo 'a.out ldconfig path:' ${_LDC}
-   ${ldconfig} -aout ${_LDC}
+   ${ldconfig} -aout ${ldc_flags} ${_LDC}
;;
esac
fi

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



Re: Bluetooth stack for FreeBSD

2002-09-10 Thread Bakul Shah

 Yes. we are aware of the work and we are pleased that it is hapenning, but
 few of us have even SEEN any bluetooth stuff yet.. 
 certainly in the US it's not yet being marketted a lot.

Fry's Electronics in the SF bayarea has a bunch of bluetooth
gadgets.  Go to www.outpost.com and search for 'bluetooth'.

USB adapters, pcmcia card, printer adapter, connectors for
Palm and iPAQ etc.  The printer adapter looks just like a
standard paraller port connector with a RJ11 or RJ45 socket
on one side (you can hook up a serial cable to it too).

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



Re: aout support broken in gcc3

2002-09-04 Thread Bakul Shah

 You are blowing this out of proportion and not actually reading
 what people are proposing.  So far, the comments are about
 removing a.out support from the base compiler and offering
 a.out binutils and gcc _as ports_.

A port is fine -- but this was proposed much later in the
thread.

  Unfortunately there is no such direct back-pressure in the
  open source community and developers usually don't have a
  long term view.
 
 Thank you for insulting our intelligence.

Sorry you see it that way -- I certainly didn't mean to
insult anyone's intelligence.  It is just the way I see it --
programmers want to program neat new things (or clean up
code or make thinge more elegant, faster, more modular, more
generic and so on) and users just want to continue using what
they are comfortable with -- even when they want to play with
new and shiny things.  I believe both groups should
participate in deciding the direction FreeBSD takes.  That is
what will bring out the best without breaking old things.

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



Re: aout support broken in gcc3

2002-09-03 Thread Bakul Shah

   Where exactly does GCC fit into the mix, making this impossible?
  
  They compile Lisp (etc) to a C file, which they compile (with gcc) to
   ^^^
 actually with as(1), because gcc is only generates assembler file,
 which is then translated into the object file by assembler (as).
 Assembler by itself is part of binutils, not a compiler suite.

I suspect Richard Tobin was using the generally accepted
meaning for a compiler as one that translates a source
program into object code (machine language).  In any case, it
is cc1 that generates an assembly file.  gcc is just a driver
program that calls various subprograms.

Richard's main point with which I totally agree is that
please do not take away the ability to generate and grok
a.out files *if at all possible*.  A number of Lisp systems
as well as Scheme one use ld -A  friends to do what he
described.  In general, please do not break backward
compatibility.

meta-discussion
Seems to me that most of the FreeBSD developers are not heavy
3rd part software users.  Consequently they (the developers)
do not realize that even when sources are available it is not
always easy to update them to support changes that break old
code -- due to lack of time or money or inability or
inexperience to change the 3rd party software or whatever.
When sources are not available, you are up the proverbial
creek.

You may say just continue running old freeBSD kernels but the
constant stream of security fixes makes hard to justify doing
that.

IMHO what is needed is a strong voice for the *users* (along
with hackers/developers) in influencing the direction FreeBSD
takes -- right now if you don't hack FreeBSD code, you don't
get listened to very much.  This is like letting a builder
build a house, or worse, letting an architect design a house
without input from the people who are going to live in it
[trust me, you want a 4000 sq ft house on your 4500 sq ft
lot, with humongous walkin closets, tiny bedrooms, a big
master bathroom with large french windows in the shower (so
what if it is facing your neighbor's living room windows only
10 ft away)].

In a commercial setting it is the user who ultimately pays
the development costs so they do get listened to (or the
company dies).  As an example, on a modern SGI machine you
can still run 20 year old binaries -- providing such
compatibility is a pain and not pretty but to long time
users' their dusty decks are very valuable.

Unfortunately there is no such direct back-pressure in the
open source community and developers usually don't have a
long term view.
/meta-discussion

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



Re: pkg_add broken by POLA breakage in tar

2002-08-01 Thread Bakul Shah

My recollection matches what Bruce says (and I have been
using unix since when version 7 was the latest and greatest).
At least the SUN OS 5.6 man page I could locate online says
this:

 The o function modifier is only valid with the x function. p
 Restore the named files to their original modes, and ACLs if
 applicable, ignoring the present umask(1). This is the
 default behavior if invoked as super-user with the x
 function letter specified. If super-user, SETUID and sticky
 information are also extracted, and files are restored with
 their original owners and permissions, rather than owned
 by root.

This superuser behavior is what allows one to use tar as an
archiving program.

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



Re: mount_nfs -T breakage

2002-07-26 Thread Bakul Shah

 Yes, that code is very broken indeed. It probably was supposed to
 call __rpc_setconf(udp) and not getnetconfigent(udp), but that
 seems to pick up an ipv6 address. I think the best plan is to go
 back to the way that part of the code was before revision 1.10.
 
 Could you try the following patch?

Thank you for the patch!  Yes, it works.  Right after I sent
out my message I tried an almost identical patch which also
worked but, as I said I don't understand this code, didn't
have time to understand it and my patch seemed a bit hacky so
I kept quiet.  Actually this whole routine seems hacky -- why
look up udp when you are told explicitly to use tcp?  Oh
well, I should keep quiet until I really understand it:-)

Thanks again!

-- bakul

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



mount_nfs -T breakage

2002-07-24 Thread Bakul Shah

TCP mount of nfs seems to be broken.

# mount bar:/usr /mnt
[tcp] bar:/usr: RPCPROG_NFS: RPC: Unknown protocol

I tracked this down to lib/libc/rpc/rpcb_clnt.c.  Seems like
the problem is in __rpcb_findaddr_timed().

diff -r 1.9 rpcb_clnt.c 
--- rpcb_clnt.c 22 Mar 2002 23:18:37 -  1.9
+++ rpcb_clnt.c 11 Jul 2002 16:23:04 -  1.10
...[deleted]...
@@ -672,13 +731,15 @@
  * starts working properly.  Also look under clnt_vc.c.
  */
 struct netbuf *
-__rpcb_findaddr(program, version, nconf, host, clpp)
+__rpcb_findaddr_timed(program, version, nconf, host, clpp, tp)
rpcprog_t program;
...[deleted]...
@@ -710,22 +777,31 @@
 */
if (strcmp(nconf-nc_proto, NC_TCP) == 0) {
struct netconfig *newnconf;
+   void *handle;
 
-   if ((newnconf = getnetconfigent(udp)) == NULL) {
+   if ((handle = getnetconfigent(udp)) == NULL) {
+   rpc_createerr.cf_stat = RPC_UNKNOWNPROTO;
+   return (NULL);
+   }
+   if ((newnconf = __rpc_getconf(handle)) == NULL) {
+   __rpc_endconf(handle);
rpc_createerr.cf_stat = RPC_UNKNOWNPROTO;
return (NULL);
}
client = getclnthandle(host, newnconf, parms.r_addr);
-   freenetconfigent(newnconf);
+   __rpc_endconf(handle);
} else {
client = getclnthandle(host, nconf, parms.r_addr);

Notice how newnconf, the second arg of getclnthandle(), is
derived.  Previously it was the output of getnetconfigent()
while now it is output of __rpc_getconf().  It expects its
arg to be of type ``struct handle*'', but it is given an arg
of type ``struct netconfig*''  The two structs are not congruent.

I don't really understand this code so I don't know what the real
fix is.

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



suspend bug

2002-07-18 Thread Bakul Shah

Try this:

$ csh
% su
Password:
% stop $$

Suspended (signal)
%fg

At which point you will lose you login shell.

Prior to KSE one could switch between an su'ed shell and a
normal shell at will by using stop $$ and fg.

Is this breakage considered a bug or a feature?

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



Re: Interesting panic very early in the boot

2002-07-17 Thread Bakul Shah

 I believe setting DISABLE_PSE in the config file and rebuilding
 will make this go away.

Terry, thanks for the suggestion but that didn't do it.
Time to review recent changes and single step the kernel.
BTW, how do you stop the kernel before it panics?  It
panics so early that there is no time for sending a break.

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



Re: Interesting panic very early in the boot

2002-07-17 Thread Bakul Shah

 That there could be a real error in that code surprises me, since
 Peter really knows what he's doing, even if that low in the
 hardware, there are undocumented interactions that even Intel's
 errata doesn't seem to know about.

Turns out the workaround is to use DISABLE_PG_G.

Two things made me try this.  One: In his commit of pmap.c
and locore.s on 7/12 7:56 Peter had this to say:

 +--
 |- Try and fix some very bogus PG_G and PG_PS interactions that were bad
 |  enough to cause vm86 bios calls to break.  vm86 depended on our existing
...
 |New option:  DISABLE_PG_G - In case I missed something.
 +--

Two: cvs diff -r1.336 -r1.337 of i386/pmap.c showes that
#ifdef SMP was changed to ifndef DISABLE_PG_G and it is in
here that pfeflag is set (pfeflag is what guards the code at
the crash site!).

 set boot_ddb

Didn't do this.

 set boot_gdb

Did this.  I though the above two were mutually exclusive options.
boot_ddb should be renamed to start_in_debugger or something.

Though boot -d is what I was really looking for.

 higher/later code, the root cause is catually in locore.s.  Happy
 bug hunt!  ;^).

Thanks but looks like I easily escaped from the hunt this
time :-)

-- bakul

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



Re: Interesting panic very early in the boot

2002-07-16 Thread Bakul Shah

I've run into a very similar bug -- the kernel panics almost
right after it is started by the loader.  With remote gdb
I've traced it to this point so far:

(kgdb) target remote /dev/cuaa0
Remote debugging using /dev/cuaa0
pmap_set_opt () at /usr/src/sys/i386/i386/pmap.c:449
449 if (*pte)
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
warning: shared library handler failed to enable breakpoint
(kgdb) where
#0  pmap_set_opt () at /usr/src/sys/i386/i386/pmap.c:449
#1  0xc0307c64 in pmap_bootstrap (firstaddr=3146924, loadaddr=0)
at /usr/src/sys/i386/i386/pmap.c:403 
#2  0xc03056b2 in getmemsize (first=4947968)
at /usr/src/sys/i386/i386/machdep.c:1473
#3  0xc0305e2f in init386 (first=4947968)
at /usr/src/sys/i386/i386/machdep.c:1817
(kgdbl
444 /* Turn on PG_G for text, data, bss pages. */
445 va = (vm_offset_t)btext;
446 endva = KERNBASE + KERNend;
447 while (va  endva) {
448 pte = vtopte(va);
449 if (*pte)
450 *pte |= pgeflag;
451 va += PAGE_SIZE;
452 }
453 invltlb();  /* Insurance */
(kgdb) p/x va
$2 = 0xc012be70

I can't get to pte for some reason.  So hand computing vtopte(va) we get

(kgdb) p/x btext
$3 = 0xc012be70
(kgdb) p PTmap
$7 = 0xbfc0
(kgdb) p/x PTmap+0xc012b
$8 = 0xbff004ac

This address matches the page fault address.  It is a
supervisor read, protection violation fault.

More details:

This is with today's (July 16) kernel (synced at about 5PM
PDT) on a Ppro system.  This system can take two PPros but
I've plugged in just one Pentium Pro.  It has 64MB ECC
memory.  I'll continue investigating but I haven't been in
this part of code for ages hence the call for help!

If it matters, a kernel built from sources before the KSE
changes works fine on this machine.

Thanks for any hints.

-- bakul

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



Re: Please test PAUSE on non-Intel processors

2002-05-24 Thread Bakul Shah

$ dmesg | head | tail -4 
CPU: AMD Athlon(tm) XP 1700+ (1466.51-MHz 686-class CPU)
  Origin = AuthenticAMD  Id = 0x662  Stepping = 2
  
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
  AMD Features=0xc048b19,AMIE,DSP,3DNow!
$ ./pt
Testing PAUSE instruction:
Register esp changed: 0xbfbff860 - 0xbfbff824

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



Re: multi default routes in freebsd !?

2002-05-21 Thread Bakul Shah

 BGP is a better idea (of course).
 
 You might also consider using BGP.
 
 And have I mentioned BGP?  8-) 8-).

Whether to use BGP/OSPF is orthogonal to multipath use.  Both
OSPF and BGP allow you to install multiple next hops.  Adding
multipath support requires, at a minimum, changing struct
rtentry to store multiple `gateways' (which are really next
hops).  You also need to fix up code to do the right thing
when adding a new route or deleting an existing route (for
example, a route is not considered dead until paths all next
hops are dead).  For forwarding a packet you can always use
the first next hop to start with but very likely you'd want
to change the forwarding code and use some policy to pick a
next hop.  Typically you'd want to use the same next hop for
a given source so as to not mess up TCP RTT calculations.

start meta discussion
Seems to me that the needs of client, server and router
machines are different enough that the networking stack code
needs to be much more flexible.  One can always put in the
most elaborate solution and just not use fancier features for
client machines but then every one pays the cost of
complexity.  Not sure what is the right thing to do here.
Anyone care to pontificate?

The same situation exists w.r.t. a number of other features.
/start meta discussion

-- bakul

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



Re: mergemaster(8) broken -- uses Perl

2002-05-19 Thread Bakul Shah

 Paul Herman [EMAIL PROTECTED] wrote:
  On Sun, 19 May 2002, Dima Dorfman wrote:
  
   How about fixing ls(1) to output the numeric mode if asked to?
  
  That's good, but while you're at it you'd probably want to get
  *everything* out of (struct stat) and print it numerically (device,
  flags, atime since epoch, etc.)  You could do this in ls(1), but
  I'll have a patch for fstat(1) soon (working on it) that gives you:
  
  bash$ /usr/obj/usr/src/usr.bin/fstat/fstat -s /tmp /kernel
  INODE  DEVSIZE BLOCKS MODE   FLAGS  LNK UID GID ATIME  MTIME CTIME 
 NAME
  235226304 4114305  8096   100555 40 1   0   0   1021779222 
10217403541021740354 /kernel
  56651  226304 512  4  041777 00 6   0   0   1021787523 
10217876571021787657 /tmp
  
  so you can parse it however you like.  Either way, ls(1) or
  fstat(1), as long as you can get the info you need.  :-)
 
 This looks much better than my extention.  I look forward to seeing
 this get into the tree.

I have a yet another variation, called `stat'.  It is like
ls(1) except you specify what stat fields you want using a
printf style format string.  I added -n flag to print out
numeric values instead of symbolic ones where it makes sense.
I originally wrote it many years ago because access to stat
fields from shell scripts is such a pain.  Yours for asking.

$ stat -h
Usage: stat [-a | -f format] [-h] [-n] [-L] files...
  where options are:
-a  print all attributes
-f format   print using a printf like format
-h  this help message
-L  follow symbolic links
-n  prints numeric values not symbolic values
The -f format is as follows:
  \ escapes are as in printf
  any other non % char is printed as is, %% prints a single %
  a stat field is printed using %[-][width][.width]letter format.
  - for left justification, width[.width] is as for %s format of printf
 letter can be one of:
   a  file access time
   b  allocated blocks
   c  inode change time
   d  dev
   f  flags
   g  group
   G  generation
   l  links
   m  file modify time
   n  file name
   p  permissions: r=read w=write x=exec S=suid/sgid s=suid/sgid+x
   T=sticky t=sticky+x
   r  raw dev
   s  size
   t  type: b=block c=char d=dir -=file p=fifo s=socket l=symlink w=whiteout
   u  user
 The default format is %t%p %2l %-6u %-6g %9s %m %n\n
 Format for the -a option is %a|%b|%c|%d|%f|%g|%G|%i|%l|%m|%p|%r|%s|%t|%u|%n\n

$ stat stat
-rwxr-xr-x  1 bakul  bakul  22523 May 18 23:46:16 2002 stat
$ stat -a stat

-- bakul

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



Re: mergemaster(8) broken -- uses Perl

2002-05-19 Thread Bakul Shah

 $ stat -a stat

Oops!  A few lines got eaten!

$ stat -a stat
May 19 00:24:42 2002|48|May 19 00:24:42 2002|291846|-|bakul|0|262301|1|May 19 00:24:42 
2002|rwxr-xr-x|1095744|23996|-|bakul|stat
$ stat -a -n stat
1021793082|48|1021793082|291846|0|1001|0|262301|1|1021793082|755|1095744|23996|10|1001|stat

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



stat(1) (was Re: mergemaster(8) broken -- uses Perl

2002-05-19 Thread Bakul Shah

 the trick nicely (but is too ``complicated'', and I'd still like
 having a tool that allows userland to call stat/fstat(2):

You are not alone; a number of stat(1) commands seemed to
have popped up over the years.  My friend @ SGI told me IRIX
also has such a command.  I liked its options so I modified
mine to match its options as well as kept the option to
specify output format.

New options:

-a atime
-c ctime
-d dev
-g group
-i inode
-k kind (dir/file/fifo/symlnk/char/block/socket/whiteout)
-l links
-m mtime
-p permissions
-r rdev
-s size
-t all three times
-u user

-q quite (print numeric values, no syntactic sugar)
-f fd fstat on file descr. fd

For BSD stuff I added

-F flags
-G generation
-b blocks
-B blocksize

Also,
-L use lstat instead of stat
-n print name
-% fmt user specified format

fmt specification as shown in my previous email, except use
%k for kind and %t for printing all three times.

By default it prints all the stat fields instead of mimicing
ls -lTd as before.  You can specify STATFMT env. var for
a default format.

Example:

$ stat -p stat
rwxr-xr-x
$ stat -p -q stat
755

Not having used SGI's stat command I don't know what output
format it uses.

Paul Herman asks in a separate email if there is a happy
medium.  I don't think so.  One can use ls(1) for a more
human readable format.  stat(1) is really for script use.
Even the -% format is for that (to avoid having to pull out
the ginsu knife of awk/sed/perl for common uses).  About the
best I can do in 300 or so lines of code and that is already
a lot of lines for something like this.

-- bakul

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



Re: size of /usr/src

2002-01-16 Thread Bakul Shah

Your questions belong to freebsd-questions!

 I created a separate partition for /usr/src (around 420MB) and cvsup ran
 out of space.  Can someone give me a rough idea of how big it is?  Also,
 I should be able to use growfs (after booting off of a floppy) to increase
 the size of the partition (if the slice has space), right? How about moving
 partitions - is there an easier way than creating a partition at the end
 of the slice and copying partitions down?

Are you creating a 5.0-CURRENT or a 4-STABLE /usr/src?

On a -STABLE:
$ du -s /usr/src
355799  /usr/src

On a -CURRENT:
$ du -s /usr/src
389637  /usr/src

FFS likes to have about 10% free space + add a few more (may
be 4%) for the inodes space.  So you need a partition of at
least 450MB.  You need to leave another 20% ~ 50% free for
future source fat (second law of computer thermodynamics).  A
partition of 1GB wouldn't hurt!

You need another 40MB or more for each kernel on whichever
partition you build them.  More if you turn debugging on.  Instead
of building kernels in /usr/src/sys/compile, you can do

cd /usr/src
make buildkernel KERNCONF=foo

to build them in /usr/obj/usr/src/sys/.

You don't need to boot from a floppy -- just unmount the
partition.  In case of the root partition you can growfs if
you boot in single user.  I believe initially the root
partition is mounted read-only so growfs change are safe.  I
would reboot immediately afterwards though.

For moving partitions I would use dump/restore to/from a
networked machine rather than copying them around.  For that
you may need to boot from a floppy.

Or you can just install released kernels and do something
worthwhile (like build some furniture) in the time you will
save :-)

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



Re: RFC: hack volatile bzero and bcopy

2001-09-07 Thread Bakul Shah

 well this is th idea, because I think that bcopy is probably a safe
 operation 
 on the volatile structures if the driver knows that they are presently
 owned by it.. (e.g. mailboxes)

*probably* safe?  For truly volatile memory bzero  bcopy are
*not* safe.   Anyone remember the origial 68000's `clr'
instruction that did read followed by write to clear memory?
You _can_ use that clr instn in bzero if the passed in ptr
does not point to volatile memory.  bcopy can also use
efficiency tricks if the src  dst are not aligned on the
same 4 byte boundary.  AMD 29k for example had an `extract'
instruction that allowed unaligned copying at memory
bandwidth.  But usually one punted on boundary conditions and
didn't think twice about refetching a word.  One can't be so
cavalier if bcopy accepted volatile ptrs.  You can use
similar tricks on systems with wide cache lines and some of
these tricks would be illegal on volatile memory.

 out-of order is probably ok for a buffer if you know that it's
 presently yours to write into.

If the area being bcopied/bzeroed has this behavior why not
remove the volatile from the struct ptrs instead of fixing
bcopy/bzero?

 2/ add to the prototype of bzero and bcopy so that volatile pointers are
 acceptable 
 arguments. (I don't see any reason to not do this).

Because the (informal) defn of bcopy/bzero does not allow
volatile arguments.  You are wagging the dog.

Why not just cast these ptrs at the call sites where you
_know_ bcopy, bzero use is safe.  That sort of documents what
is going on without opening a big hole.

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



Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS

2001-09-06 Thread Bakul Shah

  $ size scheme 
 textdata bss dec hex filename
6134244763480   69298   10eb2 scheme
 
 Is that statically-linked?  I'm curious to know the size of the bootloader
 forth footprint.  The loader is about 150k, so I'm sure you could probably
 fit a nice Scheme interpreter in under that size... ??

Dynamically linked.  Here is the statically linked size:

$ size scheme
   textdata bss dec hex filename
 127659   110929236  147987   24213 scheme

Note that this is misleading because in order to build a
standalone binary you'd have to reduce libc dependence quite
a bit.  Basically avoid anything that makes a syscall.  You
can also throw out printf and friends, which will save you
over 10KB!  On the other side you'd have to add loader
specific code (either in Scheme or in c).

Here is the /boot/loader size for comparison sake:

textdatabss dec hex
4096147456  0   151552  25000

  Tinyscheme is a mostly complete R5RS Scheme (R5RS is the
 
 You can also conditionally-compile the components to make a smaller
 footprint.  I'm highly in favor of Scheme replacing 4th...  It's a very
 easy language to learn (only 11 special forms) yet still powerful (you
 can't pass code as data in BASIC ;).  If you replace the boot loader
 interpreter, pick Scheme over LISP.  There are lots of implementations:
 siod, scm, mit-scheme, MzScheme, and tinyscheme are among the better ones.

Indeed.

But ultimately someone has to do the actual work for this to
go beyond mere wishful thinking.  I'd be happy to help out
(but not take on the whole task) if anyone braves the
naysayers :-)

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



Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS

2001-09-05 Thread Bakul Shah

  I doubt if the bootloader will ever change from FORTH, but if it
  does, I suggest LISP as the preferred choice on a short-list of
  potential replacements.
 
 Show us a suitable LISP interpreter, then.

I don't know what size constraints the bootloader has to have
but the smallest two lisp interpreters I have found are:

$ cd /usr/ports/lang/slisp/work/slisp-1.2/src
$ size slisp
   textdata bss dec hex filename
  17872 6163584   220725638 slisp

$ wc *.h *.c
  67 3212266 extern.h
  69 3352053 slisp.h
 9272438   15990 funcs.c
 189 7304707 lexer.c
 147 4583232 main.c
 287 8326358 object.c
 136 4703370 parser.c
18225584   37976 total

slisp has most of the common lisp constructs.

$ cd ~/lang/Scheme/tinyscm-1.27
$ size scheme 
   textdata bss dec hex filename
  6134244763480   69298   10eb2 scheme
$ wc *.h *.c
  12  33 247 dynload.h
 34411369221 scheme.h
 126 2922589 dynload.c
4445   12353  125421 scheme.c
4927   13814  137478 total

Tinyscheme is a mostly complete R5RS Scheme (R5RS is the
closest thing to a Scheme standard) -- everything except
complex and rational number types, bignums, hygenic macros
and call-with-values and unwind-protect.  You can probably
subset it quite a bit to make it far smaller (e.g. the real
number type and advanced math functions to avoid linking in
libm).  If it matters to you, it has a BSD style licence.

http://tinyscheme.sourceforge.net/home.html
http://tinyscheme.sourceforge.net/tinyscheme-1.27.tar.gz

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



Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])

2001-06-18 Thread Bakul Shah

 NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
 I like it, except it seems to be incompatible with POSIX.1-200x.

 The bug that stat(2) on a null symlink classifies the target of the symlink
 as a directory is caused by resolving the pathname to  and then not
 returning ENOENT in namei().   tends to be interpreted as . unless
 it is specially disallowed, and that's what happens here.   is only
 disallowed for the unresolved pathname.  Since the bug is in namei(), it
 affects all syscalls that deal with pathnames.  E.g., you can open()
 null symlinks; this is equivalent to opening ..

Err... not quite.  Given a path like
prefix/symlinksuffix
after the substitution of symlink with its target, the
search must start at the root if symlink target starts with
a /.  So it seems to me the _use_ of a  target symlink
(in all but the final path component position) is exactly
equivalent to the use of a / target symlink.  When used in
the final path component position, you get either the symlink
or ENOENT.  The POSIX excerpt Garrett quoted seems to match
this.

This is surprising at first but hardly worth adding a
singularity (an exception).  So IMHO for a  target symlink
used in _any place other than the final component_ it should
be treated as if it points to just /.  Matt Dillon's patch
seems to return ENOENT regardless of how a  target symlink
is used.

This is not a big deal but I care about not having
unnecessary exceptions.

[Yes, I have read through this thread]

-- bakul

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



Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat])

2001-06-18 Thread Bakul Shah

  So it seems to me the _use_ of a  target symlink
  (in all but the final path component position) is exactly
  equivalent to the use of a / target symlink.  When used in
  the final path component position, you get either the symlink
  or ENOENT.  The POSIX excerpt Garrett quoted seems to match
  this.
 
 No, because the relevant slash is in the pathname resulting from
 simple replacement of the full path prefix (prefix/symlink)
 with the symlink's contents.  Quoting Garrett's quote:

IMHO the key point is the *resulting* remaining pathname
after substitution.

Normally one would simply prepend the symlink contents
before the suffix, see if the resulting pathname starts
with a '/', if so start the search at root else start the
search at the parent of symlink.  In any case any leading
slashes are removed.  In other words the suffix bits are
not kept separately from symlink bits.  This is a simpler
implementation and seems to match what posix says.

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



skipping mouse pointer

2000-11-06 Thread Bakul Shah

I upgraded my system from the -current sources as of Aug-1 to
Nov-4 and find that now the mouse pointer skips while
dragging -- the pointer tracks mouse motion fine for a while,
then freezes and then jumps to a new location quite a few
pixels away.  The same thing happens under X as well as on a
virtual console.  Though the effect is not as pronounced on
a virtual console.  The new things I added were

device  random
options NETGRAPH
options COMPAT_LINUX
options FFS_EXTATTR
options NOBLOCKRANDOM

Also, rc.conf is considerably different since I hadn't upgraded
it in quite a while.  Has anyone else run into this?  Of course
I will remove the new options and see if the symptom goes away
but I thought I'd ask here as well...

Thanks,

-- bakul


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



Re: Archive pruning

2000-04-24 Thread Bakul Shah

 Do we really need 5 year old history?

That really depends on your point of view.

"Those who cannot remember the past are condemned to repeat it"
-- Santayana

"The only thing we learn from history is that we learn nothing from history."
-- Hegel

I am with Hegel in the very long term but what is the rush
about pruning?  Set a cron job to ask this in the year 2037!
In the short term it is valuable to trace back the genesis of
various features/bugs.  With cvs annotate you can even find
out who put in a feature or bug and bug that person about it
(as I was just this past week about something I had written
over four years back).  The networking code is so convoluted
that having all the history (which we don't) can be very
valuable in unravelling all the development strands.

-- bakul

PS: Of course, having a complete history is not the same as
reading and remembering it all but at least you have a
chance

What is missing is a tool that to easily browse through old
revisions (tkdiff is nice but not enough).  If such a tool
were available there would be many source code historians!

PPS: We should have a complete history *somewhere*.  You are
of course free to extend cvsup to prune so that *you* don't
have to keep it all.


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



Re: Kernel config utility

1999-12-15 Thread Bakul Shah

 So, would having a kernel config utility help us get better
 reviews?  I was thinking about something like an explorer-type
 thing that was divided into two panes.  On the left would be
 LINT.  Here, we would have icons representing the various
 devices.  For example, we could ahve an icon representing an
 ethernet card, another icon representing a serial port, etc.  On
 the right hand side we would have the custom kernel config file. 
 You could just drag the icons over to the right hand side to add
 devices to your kernel config.  And, of course, you could always
 just delete the icons you don't need.

You have just described some file system operations!

left pane:  ls LINT
right pane: ls KERNEL
drag an icon:   cp LINT/device/ethernet KERNEL/device

 By clicking on the icons, a properties pane would show the
 properties for this device.  Of course, there should be some way
 to represent options, such as DEVFS or SOFTUPDATES.

property pane:  vi KERNEL/ethernet
options:touch KERNEL/options/DEVFS
echo 2048  KERNEL/options/NMBCLUSTERS

 Of course, I like using vi better, but I've heard some people
 complaining about "how hard it is to configure a FreeBSD
 kernel."

Most of us like the convenience of editing one file but I
think what these `some people' are asking for is explicit
structure.  In a config represented by a plain file the
structure is implicit and the flat structure makes it hard to
group related things so you have to read comments (if any and
hopefully uptodate) to understand what option applies to what
object.  A directory would provide that structure (and allow
for extensions that you wouldn't even try with a flat file).


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



Re: removing enigma(1)

1999-12-01 Thread Bakul Shah

 With the FreeBSD 4.0 code freeze fast approaching, are there any
 compelling reasons to keep enigma (src/usr.bin/enigma) in the 
 source tree?

How dare you be so anti-bloat, living so close to Redmond?:-)
[But otherwise a nice place, Seattle.  I used to live there]

Enigma is just a format converter at this point and should be
left around (after renaming it crypt -- which is how it is
known on all Unix versions older than 10 years).  Some of us
old fogeys still have old encrypted files exhumed, from moldy
old files for which crypt is useful (and not just for
reburying).  crypt should be left around *somewhere*.  If you
have to throw something out, throw our perl [ducking for
cover...:-]


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



440fx builtin pnp `soundcard' doesn't work anymore under current

1999-09-27 Thread Bakul Shah

Running rvplayer crashes the system.  Catting a small .au
file works but a large one panics the system so I think the
problem may just be the drq difference.  I know a number of
people in the FreeBSD crowd have this system (a Toshiba
Equium 6200M -- a `good' buy 15 months back) so this can't be
an isolated problem.  I will be tracking this down but there
is some bootstrap time involved and may be someone has
already done this...

Thanks for any help!

-- bakul

I don't have the panic message handy at the moment but can
generate it if it'll help.

demsg reports:

pcm0: CS4236B at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0

My old /kernel.config used to say

pnp 1 0 os enable port0 0x534 port1 0x388 port2 0x220 irq0 5 drq0 1 drq1 3

[note: this used to work with an older current from June]

Kernel config file has

controller pnp0
device pcm0

pnpinfo dump [note: this shows drq 1  3]

# pnpinfo
Checking for Plug-n-Play devices...

Card assigned CSN #1
Vendor ID CSC0b35 (0x350b630e), Serial Number 0x
PnP Version 1.0, Vendor Version 1
Device Description: CS4236B Audio

Logical Device ID: CSC 0x630e #0
Device Description: WSS/SB
TAG Start DF
Good Configuration
DMA: channel(s) 1 
8-bit, not a bus master, count by byte, , Type A
DMA: channel(s) 0 3 
8-bit, not a bus master, count by byte, , Type A
IRQ: 5  - only one type (true/edge)
I/O Range 0x534 .. 0x534, alignment 0x4, len 0x4
[16-bit addr]
I/O Range 0x388 .. 0x388, alignment 0x8, len 0x4
[16-bit addr]
I/O Range 0x220 .. 0x220, alignment 0x20, len 0x10
[16-bit addr]
TAG Start DF
Acceptable Configuration
DMA: channel(s) 1 3 
8-bit, not a bus master, count by byte, , Type A
DMA: channel(s) 0 1 3 
8-bit, not a bus master, count by byte, , Type A
IRQ: 5 7 9 11 12 15  - only one type (true/edge)
I/O Range 0x534 .. 0xffc, alignment 0x4, len 0x4
[16-bit addr]
I/O Range 0x388 .. 0x388, alignment 0x8, len 0x4
[16-bit addr]
I/O Range 0x220 .. 0x260, alignment 0x20, len 0x10
[16-bit addr]
TAG Start DF
Sub-optimal Configuration
DMA: channel(s) 0 1 3 
8-bit, not a bus master, count by byte, , Type A
IRQ: 5 7 9 11 12 15  - only one type (true/edge)
I/O Range 0x534 .. 0xffc, alignment 0x4, len 0x4
[16-bit addr]
I/O Range 0x388 .. 0x3f8, alignment 0x8, len 0x4
[16-bit addr]
I/O Range 0x220 .. 0x300, alignment 0x20, len 0x10
[16-bit addr]
TAG End DF

Logical Device ID: CSC0001 0x0100630e #1
Device Description: GAME
TAG Start DF
Good Configuration
I/O Range 0x200 .. 0x200, alignment 0x8, len 0x8
[16-bit addr]
TAG Start DF
Acceptable Configuration
I/O Range 0x208 .. 0x208, alignment 0x8, len 0x8
[16-bit addr]
TAG End DF

Logical Device ID: CSC0010 0x1000630e #2
Device Description: CTRL
I/O Range 0x120 .. 0xff8, alignment 0x8, len 0x8
[16-bit addr]

Logical Device ID: CSC0003 0x0300630e #3
Device Description: MPU
TAG Start DF
Good Configuration
IRQ: 9  - only one type (true/edge)
I/O Range 0x330 .. 0x330, alignment 0x8, len 0x2
[16-bit addr]
TAG Start DF
Acceptable Configuration
IRQ: 9 11 12 15  - only one type (true/edge)
I/O Range 0x300 .. 0x3f8, alignment 0x8, len 0x2
[16-bit addr]
TAG End DF
End Tag

Successfully got 44 resources, 4 logical fdevs
-- card select # 0x0001

CSN CSC0b35 (0x350b630e), Serial Number 0x

Logical device #0
IO:  0x0534 0x0534 0x0534 0x0534 0x0534 0x0534 0x0534 0x0534
IRQ 5 0
DMA 1 0
IO range check 0x00 activate 0x01

Logical device #1
IO:  0x 0x 0x 0x 0x 0x 0x 0x
IRQ 0 0
DMA 4 4
IO range check 0x00 activate 0x01

Logical device #2
IO:  0x 0x 0x 0x 0x 0x 0x 0x
IRQ 0 0
DMA 4 4
IO range check 0x00 activate 0x00

Logical device #3
IO:  0x 0x 0x 0x 0x 0x 0x 0x
IRQ 0 0
DMA 4 4
IO range check 0x00 activate 0x00


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