Re: Errors from the ata disk driver

[Soren Schmidt]

It seems Andrew Gallatin wrote:
> 
> Looks like the world is safe for Promise Ultra users:
> 
> Dec 13 18:42:37 waffle /kernel.test: ad2: UDMA CRC READ ERROR blk #22057647 retrying
> Dec 13 18:49:21 waffle xntpd[122]: time reset (step) 0.389151 s
> Dec 13 19:11:45 waffle xntpd[122]: time reset (step) 0.381460 s
> Dec 13 19:35:13 waffle xntpd[122]: time reset (step) 0.459194 s
> Dec 13 19:40:47 waffle /kernel.test: ad4: UDMA CRC READ ERROR blk #16658928 retrying
> 
> Thanks!  

You're welcome :)

-Søren


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

Re: 4.0-CURRENT boot kernel, ATA_16BIT_ONLY , etc.

[Soren Schmidt]

It seems Valentin S. Chopov wrote:
> Hi,
> 
> The latest 4.0-CURRENT boot floppies are not working
> on old ISA boards with 16-bit data transfer only, and
> the installation of FreeBSD becomes impossible:( . It
> seems that in this case ATA_16BIT_ONLY is not enough -
> may be flags to ata0 controller or auto-detection as
> Soren promised will be O.K.?!

If ATA_16BIT_ONLY doesn't do it, autodetection wont either. 

What is the exact problem, there is absolutely no info in
your statement above??
Have you tried a verbose boot ??
How far does it get??
Hardware config??

-Søren


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

Re: sysinstall: is it really at the end of its lifecycle?

[Donn Miller]

"Jordan K. Hubbard" wrote:
 
> All true, I'm afraid.  All I can say is that efforts to revive the
> effort to replace sysinstall are underway and we're even trying to
> throw some money-shaped darts at the problem in hopes that we'll hit
> something.  I'm cautiously pessimistic, so we'll see. :)

As far as the successor to sysinstall goes, I think it would be
nice to have both a console version and an X version, with some X
tookit such as Lesstif or Qt, or Tcl/Tk.  It could be a lot like
RedHat's "linuxconf", where you can use it as both an installer
or system administration tool.  Not that I'm in love with
RedHat's method of doing things, but I think it would be nice to
keep sysinstall (or whatever it'd be called) as an all-in-one
tool for adding packages or for first-time installs.

Maybe we could call it "sysconfig", in honor of the old
/etc/sysconfig file that was superceded bt /etc/rc.conf.

I saw in CUBFM (the newsgroup) where a couple of people wanted to
do a GUI menu-based interfaced to the kernel configuration (as
opposed to editing a file by hand).  I don't think this would be
too hard at all, but I wondered what the experienced FreeBSD
users thought of this idea?

I was fiddling around with NetBSD-current i386 on this same
machine, and it looks really raw compared to FreeBSD.  No
offense, but they don't even have anything as nice as sysinstall
yet.  On top of that, there's no utility like we have
(userconfig) to edit device parameters before the boot procedes. 
As a result, if more than one ISA device is attached to the same
IRQ, you'll get a kernel panic on boot-up.

Of course, I realize NetBSD is more focused on being
multi-platform than we, but there's no reason they can't "borrow"
some ideas from us, such as userconfig boot editor or
sysinstall.  In return, we could borrow some of their code for
our SPARC port.  I think we should keep the lines open between us
and NetBSD/OpenBSD, so that we can exchange some ideas more
freely.


- Donn


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

Re: sysinstall: is it really at the end of its lifecycle?

[Brad Knowles]

At 2:36 AM -0500 1999/12/14, Donn Miller wrote:

>  I saw in CUBFM (the newsgroup) where a couple of people wanted to
>  do a GUI menu-based interfaced to the kernel configuration (as
>  opposed to editing a file by hand).  I don't think this would be
>  too hard at all, but I wondered what the experienced FreeBSD
>  users thought of this idea?

I saw that too.  I'm not sure I qualify as an "experienced 
FreeBSD user", but although I almost certainly would not use the tool 
myself (I like to have some inkling of what programs are doing and 
why), I can see why others might want something like this.

Myself, I'd like to see an improved installation tool to replace 
sysinstall, before we worry too much about a GUI kernel configuration 
tool, although if someone has a real bee in their bonnet to do the 
latter, I certainly wouldn't be inclined to stand in their way.

-- 
   These are my opinions -- not to be taken as official Skynet policy
  
|o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o|
|o| Systems Architect, News & FTP Admin  Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels   |o|
|o| http://www.skynet.be Belgium   |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
   Unix is very user-friendly.  It's just picky who its friends are.


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

Re: sysinstall: is it really at the end of its lifecycle?

[Jordan K. Hubbard]

> As far as the successor to sysinstall goes, I think it would be
> nice to have both a console version and an X version, with some X
> tookit such as Lesstif or Qt, or Tcl/Tk.  It could be a lot like
> RedHat's "linuxconf", where you can use it as both an installer
> or system administration tool.

Which is about correct, though there's a volume of details behind your
conceptualization of the system in outline form there. :-)

To really understand where we're trying to go, however, it's somewhat
helpful to take a good look at where we are now, e.g. stuck with our
dear friends sysinstall and the pkg_install suite.

The sysinstall program is basically nothing more than a monolithic
C program which knows how to do the following "special" things:

o Run as init, if so invoked, and do the special inity-things that must
  be done for an interactive program to subsequently function properly
  (see system.c:systemInitialize).

o How to stomp on disks directly for the purposes of partitioning,
  writing MBRs, etc.  Most of this is already abstracted by libdisk(3)
  (see also disks.c and label.c).

o How to newfs and/or mount filesystems of many different types
  (UFS, DOS, NFS, CD, floppy, etc) and how to use them as
  installation media (see media.c and friends).

o How to configure network interfaces (with or without DHCP) and
  how to use FTP servers as media devices, much of the latter
  being abstracted by ftpio(3) (see tcpip.c and network.c).

o How to read FreeBSD "distributions" (gzippied, split tarballs with
  external property (.inf) files, essentially) and extract them to
  a mounted hierarchy of UFS partitions (see dist.c).

o How to read /usr/ports/INDEX files and enough about the internals of
  packages to get the pkg_install suite to jump through many hoops you'd
  rather just not know about (see index.c and package.c).

o How to spit out hosts, resolv.conf and rc.conf files from internal
  variable state, allowing dialogs to be constructed which front-end
  much of the contents of these files (see config.c and variable.c).

o How to use the dialog(3) library in ways that should not be
  discussed within earshot of small children (see dmenu.c).

All of these capabilities adding up to a composite picture with a
number of deep and irredeemable flaws.

Let's take the UI, for example.  Even in a system as simple as
sysinstall, we have 2 screens open: the primary interaction screen on
VTY1 and the debugging information screen on VTY2 (not counting the
possible child holoshell on VTY4 or a child ppp session on VTY3).  We
put them on separate VTYs because there is no clever multithreaded UI
here which allows such output to scroll along in one window while
doing other things in another, it's basically a single thread of
control per VTY.  Anyway, this works great for most things but causes
problems the minute you want to install a package which is
interactive.  Most packages just cause pkg_add to spew various bits of
diagnostic output which you'd otherwise be perfectly happy to go onto
VTY2, but if a package suddenly takes it into its head to bring up a
menu, that's also going to go on VTY2 since sysinstall has no idea in
advance that this package might have something meaningful to say and
it's going to route its stdin and stdout to VTY2 as always.
Unfortunately, that causes consernation on the part of the user who's
staring at VTY1 meanwhile and wondering why the package is taking so
damn *long* to install.

I've seen novices wait so long that medical intervention was necessary
in order to save them, leaving us unlikely to win any Tog Awards for
interface design in such cases.  Sure, I can hear you yelling at those
novices from here: "JUST SWITCH TO THE OTHER VTY AND *LOOK*, YOU
CHEESEHEADS!", but it's never that simple.  Users will be users and
even our own annoying common-sense tells us that both pkg_add and
sysinstall should really be "rendevousing" on the user, wherever the
user's eyeballs might happen to be at the moment, and bringing up the
menu in question.  It shouldn't be over on the debugging screen and if
pkg_add were somehow a library linked into sysinstall and using the
same common UI API, initialized by sysinstall to point to VTY1 at
startup time, well then by golly that would Just Work(tm) and life
would be good again.

That's one of the design precepts of the New System, in fact.  There
is one common UI abstraction which sysinstall II (hereafter referred
to as Setup) and the new package system both use.  The generic UI
front-end API is "bound" at runtime to a back-end implementation
class, the two currently supported ones being Qt and Turbovision (the
references implementation for the common UI stuff is all written in
C++), and everything pops up in the appropriate UI environment from
that point forward.  Our test code checks for $DISPLAY and does the
appropriate Qt magic in that case, otherwise it binds in Turbovision.
In theory, one could even write a back-end class which talked to a
brow

Re: syscons extension: "propellers"

[Oliver Fromme]

I wrote in list.freebsd-current:
 > I have (long time ago) written some extensions to syscons, and
 > finally decided to clean them up, document and submit them.

Just in case somebody is curious, here's a screenshot:
http://www.fromme.com/propellers/

Regards
   Oliver

-- 
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])

"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
 (Terry Pratchett)


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

Re: syscons extension: "propellers"

[Jordan K. Hubbard]

> Just in case somebody is curious, here's a screenshot:
> http://www.fromme.com/propellers/

That looks very interesting...  It's just screaming for some kind of
mechanism which allows you to kldload the propeller code in as an
extention rather than linking it into the kernel. :)

- Jordan


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

Re: RELEASE timelines

[Matthew Thyer]

Yes 2.x went on for too long but I was counting 2.2.x as the equivalent of
3.x due to the change in the release schedule (mainly just a change in the
numberring).

The thing that worries me is the bad reputation that comes from releasing
not quite ready releases.

Basically the real way to run FreeBSD is from source ala -STABLE as we
dont have a binary patching system established like the commercial
vendors.

Its argueable that the real FreeBSD is -CURRENT considering there is no
automated method for tracking what hasn't yet been committed to -STABLE.

It seems there is always a mad rush to MFC when -STABLE is about to pop
out another release and this often leads to less than perfect releases and
sometimes downright embarrasing mistakes.

I'm not calling for a years worth of beta testing ala IRIX 6.5 but there
are probably some improvements that can be made to the release system.
After all we dont have to have the latest set of gcc, binutils, etc
whenever a release appears since we have a good ports system.

My first thought would be for cvs to be modified to require tagging of
each commit to -CURRENT with a flag to indicate whether it should be
merged into -STABLE before the next release (maybe it would indicate which
release this change should be in).  This will make it easier to process
the backlog and allow a longer testing period for -STABLE before each
release.

I hope this doesn't start too big a thread as I'm rather behind on my
cvs-all mail as it is (methinks those people who read all of current and
cvs-all must have a job that lets them do this during work time or no
wife and kids like myself).

On Tue, 14 Dec 1999, Mark Newton wrote:

> On Tue, Dec 14, 1999 at 12:34:28AM +1030, Matthew Thyer wrote:
> 
>  > Consider the 2.2 stream that went through many more releases (counting
>  > 2.2.1 -> 2.2.8).  Using that yardstick you'd expect 4.0 to stay in
>  > development until 3.7 is released.   I know 7 releases of the 2.2 stream
>  > was considerred a few too many but surely we can hold 4.0 back a bit
>  > longer considerring the age of some of the code. 
> 
> The fact that the 2.2 stream went on for so long was one of the things
> which prompted the change to the way FreeBSD release engineering occurs.
> Continuing to bang on 2.x for, what, 16 minor revisions? was a problem,
> because it held the many improvements in 3.x back from the release 
> stream for ages:  So long, in fact, that some of the developers who had
> been working on them decided to leave for greener pastures where their
> code would actually see the light of day.
> 
> Bear in mind the difference between 4.0-RELEASE and 4.1-STABLE too:
> 4.0-RELEASE will be for "early adopters" anyway.
> 
>- mark
> 
> 

-- 
/===\
| Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] |
\===/
"If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time."
 E. P. Tryon   from "Nature" Vol.246 Dec.14, 1973



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

Re: sysinstall: is it really at the end of its lifecycle?

[Brad Knowles]

At 1:49 AM -0800 1999/12/14, Jordan K. Hubbard wrote:

>   Sure, I can hear you yelling at those
>  novices from here: "JUST SWITCH TO THE OTHER VTY AND *LOOK*, YOU
>  CHEESEHEADS!", but it's never that simple.

Yup, this is me.  Been there, done that many times.  This is why 
I don't use sysinstall to actually install any packages anymore -- I 
never know which ones are going to want to be interactive.

>  No more monolithic prototypes!  Framework!  Frame-work!
>  Frame-work! [jkh jumps up on a chair and begins waving his hands
>  enthusiastically before losing his balance and toppling over with an
>  abrupt scream].

[{()}] [{()}]

"Brain hurt."

[ THUD ]

"I sit down now."

-- 
Brad Knowles <[EMAIL PROTECTED]> 
 

Your mouse has moved.   Windows NT must be restarted for the change to
take effect.   Reboot now?  [ OK ]


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

Re: make world broken building fortunes

[Marcel Moolenaar]

Peter Wemm wrote:
> 
> I wonder if we should move fortune to usr.bin?  It's hardly a game and I'm
> way beyond tired of it being left out of standard paths...
> (ie: "/bin:/usr/bin[:/usr/local/bin]")

After letting this go through my head for a day (it probably isn't
important anymore :-), I think it's better to add /usr/games to the
standard search path. Fortune is not a tool you use for anything other
than fun and does not really belong in a "serious" directory as
/usr/bin. On the other hand it's too frequently used to not have it
somewhere in a search path. Also, having games as part of FreeBSD
without a proper search path to them is also a bit odd.

Anyway, my 2c...

-- 
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking & Databases   http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]


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

Re: join the mailing-list

[Matthew Thyer]

Not this way.

Send email to "[EMAIL PROTECTED]" with the following two lines in
the body of the message:

subscribe freebsd-current
subscribe cvs-all


You should consider this action very carefully as you will start
receiving approximately 200 messages each day.

I would suggest that you only subscribe to freebsd-current to start
with.

On Tue, 14 Dec 1999, Leung Wa, Thomas Chow wrote:

> 
> 

-- 
/===\
| Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] |
\===/
"If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time."
 E. P. Tryon   from "Nature" Vol.246 Dec.14, 1973



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

Re: syscons extension: "propellers"

[Oliver Fromme]

Jordan K. Hubbard wrote in list.freebsd-current:
 > > Just in case somebody is curious, here's a screenshot:
 > > http://www.fromme.com/propellers/
 > 
 > That looks very interesting...  It's just screaming for some kind of
 > mechanism which allows you to kldload the propeller code in as an
 > extention rather than linking it into the kernel. :)

Actually, I was thinking about that myself.  But the problem
is that the code is very closely integrated into the existing
syscons code (with a lot of #ifdef's, of course).

I have never programmed a KLD before (though I will have a
look into this when I have some spare time left), but it is
my understanding that KLDs are appropriate for parts of the
kernel which can be reasonably easy separated from the rest
of the kernel.  This is not the case for the propellers code.
Well, it could possibly be done, but it would require some
major design changes to syscons.

On the other hand, the propeller code adds about 5 Kbyte to
/kernel, which isn't that much.  And of course, I'm not
voting for putting it into GENERIC.

By the way, is there interest in giving the "Print Screen"
key an appropriate meaning, i.e. capturing a screenshot?
I have a few patches for this to implement that, I'd just
have to clean the code up and write a bit of documentation.
The GIF on the above webpage was created that way (along
with a small userland tool and netpbm).  I'm just asking.
If nobody cares, I will not bother putting more time and
effort into this.

Regards
   Oliver

-- 
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])

"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
 (Terry Pratchett)


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

Re: syscons extension: "propellers"

[Luigi Rizzo]

> By the way, is there interest in giving the "Print Screen"
> key an appropriate meaning, i.e. capturing a screenshot?
> I have a few patches for this to implement that, I'd just
> have to clean the code up and write a bit of documentation.
> The GIF on the above webpage was created that way (along

i was about to ask how did you generate it!

cheers
luigi


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

Re: syscons extension: "propellers"

[Jordan K. Hubbard]

> I have never programmed a KLD before (though I will have a
> look into this when I have some spare time left), but it is
> my understanding that KLDs are appropriate for parts of the
> kernel which can be reasonably easy separated from the rest
> of the kernel.  This is not the case for the propellers code.
> Well, it could possibly be done, but it would require some
> major design changes to syscons.

Indeed, so I'd also suspected and more the reason to do so,
right?  It would make possible many other types of "dashboard"
controls as well.  Skins for syscons!  I can see it now!  Haha!
[he laughs hysterically as several burly guys in white medical
gowns leap out of a panel van, wielding hypodermic needles
and various restraints].

> By the way, is there interest in giving the "Print Screen"
> key an appropriate meaning, i.e. capturing a screenshot?

Sure, that sounds kind of interesting too. :) 

- Jordan


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

Re: syscons extension: "propellers"

[Sheldon Hearn]

On Tue, 14 Dec 1999 12:40:34 +0100, Oliver Fromme wrote:

> By the way, is there interest in giving the "Print Screen"
> key an appropriate meaning, i.e. capturing a screenshot?

YES!  This comes up at least once a month on the -questions mailing
list. :-)

Ciao,
Sheldon.


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

Re: syscons extension: "propellers"

[Donn Miller]

Oliver Fromme wrote:

> Actually, I was thinking about that myself.  But the problem
> is that the code is very closely integrated into the existing
> syscons code (with a lot of #ifdef's, of course).

I think another way (instead of ifdefs) would be to provide some
hooks into syscons, so that the "propellers" code can be loaded
or unloaded via kldload/unload.

- Donn


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

Re: syscons extension: "propellers"

[Sheldon Hearn]

On Tue, 14 Dec 1999 13:56:45 +0200, Sheldon Hearn wrote:

> YES!  This comes up at least once a month on the -questions mailing
> list. :-)

I should have been more specific.  People are dead keen on these two
features:

1) dump an ascii capture of the screen to a file.
2) dump the entire scrollback buffer to a file.

Ciao,
Sheldon.


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

Re: Speaking of moving files (Re: make world broken building fortunes )

[Matthew Thyer]

On Mon, 13 Dec 1999, Louis A. Mamakos wrote:
> So how about /usr/sbin/chown -> /sbin/chown so that MAKEDEV works with
> just the root file system mounted?   

How about removing awk from MAKEDEV so life isn't so hard to recover
when you use a 3.3 fixit floppy after removing /dev and not making
enough of it again.

-- 
/===\
| Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] |
\===/
"If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time."
 E. P. Tryon   from "Nature" Vol.246 Dec.14, 1973



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

Re: syscons extension: "propellers"

[Donn Miller]

"Jordan K. Hubbard" wrote:

> Indeed, so I'd also suspected and more the reason to do so,
> right?  It would make possible many other types of "dashboard"
> controls as well.  Skins for syscons!  I can see it now!  Haha!
> [he laughs hysterically as several burly guys in white medical
> gowns leap out of a panel van, wielding hypodermic needles
> and various restraints].

Actually, that's not a bad idea.  One idea I had was combining
syscons with XFree86 server code, so you always have a crippled X
server running without the bloat of a full-blown X server
running.  That way, you could just type "xclock", and an xclock
would pop up right on your syscons screen (without formally
starting X ;-).  

Well, the idea would be to somehow integrate the driver portion
of XFree86 into a new console driver package.  You would have
your video card type entered in /etc/rc.conf (or some other
place, such as /etc/syscons.conf).  Then, you could have the
option of loading this "enhanced" version of syscons at boot
time.  Each video driver would be loaded as a KLD.

Then, we could do something like run X apps at the virtual
console without X running.  For example, you want to run netscape
without firing up X.  You would just type "netscape", and
netscape would display right on your syscons virtual console
without having to start X proper.  What this would give us is a
way to run X11 apps as console graphics applications.  You would
lose window management, however, because the idea is to run the
apps as if they were console graphics (e.g. svgalib) apps.

One potential drawback is that it would probably bloat the
syscons code slightly.

- Donn


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

Re: syscons extension: "propellers"

[Andrzej Bialecki]

On Tue, 14 Dec 1999, Donn Miller wrote:

> Oliver Fromme wrote:
> 
> > Actually, I was thinking about that myself.  But the problem
> > is that the code is very closely integrated into the existing
> > syscons code (with a lot of #ifdef's, of course).
> 
> I think another way (instead of ifdefs) would be to provide some
> hooks into syscons, so that the "propellers" code can be loaded
> or unloaded via kldload/unload.

Another way to customize various strings, colors and variables could be
via sysctl. It's easy e.g. to set up the "propeller" string via sysctl.

Andrzej Bialecki

//  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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

Re: syscons extension: "propellers"

[Thomas David Rivers]

> 
> One potential drawback is that it would probably bloat the
> syscons code slightly.
> 
> - Donn
> 

 Uhh... "slightly"?

- Dave R. -



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

Broken sh(1): A more specific example

[Marcel Moolenaar]

Just try:

#!/bin/sh
PATH=/usr/obj/usr/src/i386/bin:/usr/obj/usr/src/i386/usr/bin:\
/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin:\
/usr/games:/usr/local/bin:/usr/X11R6/bin:/home/marcel/bin ls
ls

I get:

scones% ./y.sh
COPYRIGHT   etc share
CVS games   sys
Makefilegnu tools
Makefile.inc0   include update.out
Makefile.inc1   kerberosIV  usr.bin
Makefile.upgradelib usr.sbin
README  libexec x.out
UPDATINGmake.outx.sh
bin mkrelease   y.sh
contrib release y.sh~
crypto  sbin
diff.outsecure
./y.sh: ls: not found

I somehow think it has something to do with the size of the new PATH
variable...

-- 
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking & Databases   http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]


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

Broken sh(1)?

[Marcel Moolenaar]

Hi,

Try the following shell script (taken from a buildworld):

#!/bin/sh -ev
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/i386 \
PATH=/usr/obj/usr/src/i386/bin:/usr/obj/usr/src/i386/usr/bin:\
/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin:\
/usr/games:/usr/local/bin:/usr/X11R6/bin:/home/marcel/bin \
INSTALL="sh /usr/src/tools/install.sh" \
DESTDIR=/usr/obj/usr/src/i386 TARGET_ARCH=i386 \
MACHINE_ARCH=i386 make -f Makefile.inc1 -DNOMAN -DNOINFO \
-DNO_FORTRAN -DNO_GDB tools
cd /usr/src; make -f Makefile.inc1 par-obj

I always get the following:

===> c++filt
sh /usr/src/tools/install.sh -c -s -o root -g wheel -m 555 \
c++filt /usr/obj/usr/src/i386/usr/libexec/elf
===> doc
===> cc1obj
sh /usr/src/tools/install.sh -c -s -o root -g wheel -m 555 \
cc1obj /usr/obj/usr/src/i386/usr/libexec

cd /usr/src; make -f Makefile.inc1 par-obj
./x.sh: make: not found

^^^
At this point PATH contains /usr/bin, so I don't think it's PATH
related. 

context:

FreeBSD scones.sup.scc.nl 4.0-CURRENT FreeBSD 4.0-CURRENT #21: Sun Dec
12 19:15:04 CET 1999
[EMAIL PROTECTED]:/usr/src/sys/compile/SCONES  i386

-r-xr-xr-x  1 root  wheel  430152 Dec 11 13:05 /bin/sh

-- 
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking & Databases   http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]


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

Re: Broken sh(1): A more specific example

[Sheldon Hearn]

On Tue, 14 Dec 1999 14:48:51 +0100, Marcel Moolenaar wrote:

> #!/bin/sh
> PATH=/usr/obj/usr/src/i386/bin:/usr/obj/usr/src/i386/usr/bin:\
> /usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin:\
> /usr/games:/usr/local/bin:/usr/X11R6/bin:/home/marcel/bin ls
> ls

What do you think the shell should be doing with this malformed path?

Ciao,
Sheldon.


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

Re: Broken sh(1)?

[Sheldon Hearn]

On Tue, 14 Dec 1999 14:30:59 +0100, Marcel Moolenaar wrote:

> #!/bin/sh -ev
> cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/i386 \
> PATH=/usr/obj/usr/src/i386/bin:/usr/obj/usr/src/i386/usr/bin:\
> /usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin:\
> /usr/games:/usr/local/bin:/usr/X11R6/bin:/home/marcel/bin \
> INSTALL="sh /usr/src/tools/install.sh" \
> DESTDIR=/usr/obj/usr/src/i386 TARGET_ARCH=i386 \
> MACHINE_ARCH=i386 make -f Makefile.inc1 -DNOMAN -DNOINFO \
> -DNO_FORTRAN -DNO_GDB tools
> cd /usr/src; make -f Makefile.inc1 par-obj

You set all those variables for the first make command, but not for the
second.  What did you expect to happen?

Ciao,
Sheldon.


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

Re: Broken sh(1): A more specific example

[Marcel Moolenaar]

Sheldon Hearn wrote:
> 
> On Tue, 14 Dec 1999 14:48:51 +0100, Marcel Moolenaar wrote:
> 
> > #!/bin/sh
> > PATH=/usr/obj/usr/src/i386/bin:/usr/obj/usr/src/i386/usr/bin:\
> > /usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin:\
> > /usr/games:/usr/local/bin:/usr/X11R6/bin:/home/marcel/bin ls
> > ls
> 
> What do you think the shell should be doing with this malformed path?

I assume you all understand that this was a simple invocation of
PATH=something ls. You all heard of line-continuation didn't you?

Anyway, try this:

scones% sh
% PATH=/foobar:$PATH ls

% ls
ls: not found

-- 
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking & Databases   http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]


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

Re: Broken sh(1)?

[Marcel Moolenaar]

Sheldon Hearn wrote:
> 
> On Tue, 14 Dec 1999 14:30:59 +0100, Marcel Moolenaar wrote:
> 
> > #!/bin/sh -ev
> > cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/i386 \
> > PATH=/usr/obj/usr/src/i386/bin:/usr/obj/usr/src/i386/usr/bin:\
> > /usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin:\
> > /usr/games:/usr/local/bin:/usr/X11R6/bin:/home/marcel/bin \
> > INSTALL="sh /usr/src/tools/install.sh" \
> > DESTDIR=/usr/obj/usr/src/i386 TARGET_ARCH=i386 \
> > MACHINE_ARCH=i386 make -f Makefile.inc1 -DNOMAN -DNOINFO \
> > -DNO_FORTRAN -DNO_GDB tools
> > cd /usr/src; make -f Makefile.inc1 par-obj
> 
> You set all those variables for the first make command, but not for the
> second.  What did you expect to happen?

That make(1) would execute.

-- 
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking & Databases   http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]


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

sh(1) broken caching [was: Re: Broken sh(1)?]

[Marcel Moolenaar]

Sheldon Hearn wrote:
> 
> On Tue, 14 Dec 1999 15:42:11 +0100, Marcel Moolenaar wrote:
> 
> > > You set all those variables for the first make command, but not for the
> > > second.  What did you expect to happen?
> >
> > That make(1) would execute.
> 
> But what was the PATH set to _before_ you set it for the first execution
> of make?  That's what's important, surely?

It is. Try this:

scones% sh
% echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin:
% hash -v
builtin hash
builtin echo
% which ls
/bin/ls
% hash -v
builtin hash
builtin echo
/usr/bin/which
% PATH=/foo:/bar:/bin ls

% hash -v
builtin hash
builtin echo
/usr/bin/which
/usr/sbin/ls
 Caching index based on temp. path
% ls
ls: not found

QED :-)

-- 
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking & Databases   http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]


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

configure problems

[Pascal Hofstee]

Hi,

I have noticed some weird problems lately when running configure-scripts.
E.g. when trying to build the gtk12-port configure just hangs waiting for
"conftest" to finish (which never seems to do so).  I have noticed
similair problems with other configure checks (e.g. SDL).

Is this a known issue and/or is there any way to solve this problem ?

This is on a FreeBSD-current system as of last night.
(Noticed the problem occuring for several days now)


  Pascal Hofstee - [EMAIL PROTECTED]

-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS d- s+: a-- C++ UB P+ L- E--- W- N+ o? K- w--- O? M V? PS+ PE Y-- PGP--
t+ 5 X-- R tv+ b+ DI D- G e* h+ r- y+
--END GEEK CODE BLOCK--



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

Re: configure problems

[David O'Brien]

On Tue, Dec 14, 1999 at 05:00:14PM +0100, Pascal Hofstee wrote:
> I have noticed some weird problems lately when running configure-scripts.
> E.g. when trying to build the gtk12-port configure just hangs waiting for

Please repost this in [EMAIL PROTECTED] as that is the proper list for
ports-related questions (which this is).

[EMAIL PROTECTED] is for issues surounding the bleading edge
development in the base system.

-- 
-- David([EMAIL PROTECTED])


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

PCM/AD1816

[German Tischler]

Hi.

Would someone please fix recording for the Ad1816 chip in the
newpcm code ? (the problem is, that the dma is started on the
wrong channel, because the channel number is not initialized
during setup.) I've already sent a patch to the maintainer
but it seems he didn't like it.

-- 
German Tischler, [EMAIL PROTECTED]

"There are two major products that come out of Berkeley:
LSD and Unix. We don't believe this to be a coincidence."
 -- Jeremy S. Anderson




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

Re: Speaking of moving files (Re: make world broken building fortunes )

[Ben Rosengart]

On Mon, 13 Dec 1999, Bill Fumerola wrote:

> On Mon, 13 Dec 1999, Louis A. Mamakos wrote:
> 
> > So how about /usr/sbin/chown -> /sbin/chown so that MAKEDEV works with
> > just the root file system mounted?   
> 
> As one who just got his ass bitten by this, I would vote yes.

As one who's missed chown at times when only root's mounted, I'm with Bill.

--
 Ben Rosengart

UNIX Systems Engineer, Skunk Group
StarMedia Network, Inc.



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

Re: syscons extension: "propellers"

[Nik Clayton]

On Tue, Dec 14, 1999 at 12:40:34PM +0100, Oliver Fromme wrote:
> By the way, is there interest in giving the "Print Screen"
> key an appropriate meaning, i.e. capturing a screenshot?
> I have a few patches for this to implement that, I'd just
> have to clean the code up and write a bit of documentation.
> The GIF on the above webpage was created that way (along
> with a small userland tool and netpbm).  I'm just asking.
> If nobody cares, I will not bother putting more time and
> effort into this.

Yes.  I've got some patches somewhere for 2.2x syscons that implemented
an ioctl for this, the idea being that these screenshots can then be used
in the FAQ and Handbook as necessary.  I didn't get around to sorting this
out, which is why I never re-integrated them after the big syscons change
that happened when -current became 3.0.

N
-- 
If you want to imagine the future, imagine a tennis shoe stamping
on a penguin's face forever.
--- with apologies to George Orwell


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

Re: syscons extension: "propellers"

[Nik Clayton]

On Tue, Dec 14, 1999 at 02:42:52PM +0200, Sheldon Hearn wrote:
> On Tue, 14 Dec 1999 13:56:45 +0200, Sheldon Hearn wrote:
> 
> > YES!  This comes up at least once a month on the -questions mailing
> > list. :-)
> 
> I should have been more specific.  People are dead keen on these two
> features:
> 
>   1) dump an ascii capture of the screen to a file.
>   2) dump the entire scrollback buffer to a file.

We need more than just an ASCII capture.  Grabbing the colour information
is also very useful.  This lets you make full colour pictures of things
like sysinstall.

If anyone's interested, I've still got the old patches to syscons (which
were mostly the work of a third party -- I'm damned if I can find out who
sent them to me in my mail archive though) and a little utility that converts
from the PC text mode screen format (each char described by 2 bytes, 1st 
byte is ASCII value, second byte is colour, where top nybble is background
colour, bottom nybble is foreground colour).  It also reads and decodes the
same font files that syscons uses, so the GIF it outputs is as near as damn
it identical to what was on the screen originally.

Source code available free to a good home :-)

N
-- 
If you want to imagine the future, imagine a tennis shoe stamping
on a penguin's face forever.
--- with apologies to George Orwell


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

Last ATA checkin broke the IDE drive on my Toshiba Portege

[Mikael Hybsch]

Got myself a Toshiba Portégé 3110CT last week. The IDE controller
isn't recognized by the ata driver. It's an Intel(0x8086) with the
device ID 0x7199. Until the last DMA related checkins by Søren, the drive
was working in PIO mode.

Now it says it's using DMA and after the "Mounting root from ..." message,
I get
ad0: ad_timeout: lost disk contact - resetting
ata0: resetting devices .. 
and then it hangs with the disk activity led on.

Todays ata checkin said "Try to enable DMA on generic controllers ...",
but it still doesn't work. Now it also
says "ata0: master: success setting up WDMA2 mode on generic chip".

The wdc driver seems to work ok with the 0xa0ffa0ff flags.

I have tried looking around on developer.intel.com, but couldn't find
any reference to the device ID 0x7199. Where can I find which chipset
this is?

boot -v from last working PIO mode below


Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #1: Sun Dec 12 23:52:16 GMT 1999
root@h:/usr/src/sys/compile/H
Calibrating clock(s) ... TSC clock: 299933222 Hz, i8254 clock: 1193150 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254"  frequency 1193182 Hz
CLK_USE_TSC_CALIBRATION not specified - using old calibration method
CPU: Pentium II/Celeron (299.94-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x66a  Stepping = 10
  
Features=0x183f9ff
real memory  = 134086656 (130944K bytes)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x0030d000 - 0x07fd7fff, 130854912 bytes (31947 pages)
avail memory = 126955520 (123980K bytes)
bios32: Found BIOS32 Service Directory header at 0xc00f0220
bios32: Entry = 0xfc455 (c00fc455)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xedcd
pnpbios: Found PnP BIOS data at 0xc00f8ed0
pnpbios: Entry = f:9344  Rev = 1.0
pnpbios: Event flag at 510
pnpbios: OEM ID 1934f351
Other BIOS signatures found:
ACPI: 000f0170
Preloaded elf kernel "kernel" at 0xc02f4000.
Pentium Pro MTRR support enabled
md0: Malloc disk
Creating DISK md0
pci_open(1):mode 1 addr port (0x0cf8) is 0x
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=71948086)
npx0:  on motherboard
npx0: INT 16 interface
pci_open(1):mode 1 addr port (0x0cf8) is 0x
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=71948086)
pcib0:  on motherboard
found-> vendor=0x8086, dev=0x7194, revid=0x01
class=06-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
found-> vendor=0x1023, dev=0x9525, revid=0x49
class=03-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=11
map[10]: type 1, range 32, base ff40, size 22
map[14]: type 1, range 32, base ff3e, size 17
map[18]: type 1, range 32, base fec0, size 22
found-> vendor=0x8086, dev=0x7198, revid=0x01
class=06-80-00, hdrtype=0x00, mfdev=1
subordinatebus=0secondarybus=0
found-> vendor=0x8086, dev=0x7199, revid=0x00
class=01-01-80, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
map[20]: type 1, range 32, base fff0, size  4
found-> vendor=0x8086, dev=0x719a, revid=0x00
class=0c-03-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=d, irq=11
map[20]: type 1, range 32, base ff80, size  5
found-> vendor=0x8086, dev=0x719b, revid=0x00
class=06-80-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
found-> vendor=0x1179, dev=0x0d01, revid=0x00
class=0d-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=11
map[10]: type 1, range 32, base ff60, size  5
found-> vendor=0x1179, dev=0x0617, revid=0x20
class=06-07-00, hdrtype=0x02, mfdev=1
subordinatebus=14   secondarybus=14
intpin=a, irq=255
found-> vendor=0x125d, dev=0x1978, revid=0x10
class=04-01-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=11
map[10]: type 1, range 32, base fc00, size  8
found-> vendor=0x11c1, dev=0x0441, revid=0x01
class=07-80-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=3
map[10]: type 1, range 32, base ffefff00, size  8
map[14]: type 3, range 32, base 02f8, size  3
map[18]: type 1, range 32, base 1c00, size  8
found-> vendor=0x8086, dev=0x1229, revid=0x08
class=02-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=11
map[10]: type 1, range 32, base febff000, size 12
map[14]: type 1, range 32, base fb40, size  6
m

Re: Speaking of moving files (Re: make world broken building fortunes )

[Matthew Dillon]

:> 
:> > So how about /usr/sbin/chown -> /sbin/chown so that MAKEDEV works with
:> > just the root file system mounted?   
:> 
:> As one who just got his ass bitten by this, I would vote yes.
:
:As one who's missed chown at times when only root's mounted, I'm with Bill.
:
:--
: Ben Rosengart
:
:UNIX Systems Engineer, Skunk Group
:StarMedia Network, Inc.

I think at one time or another all of us have missed *something* in
/usr that wasn't in /.  For example, disklabel -e doesn't work without
vi -- which is in /usr.

But if we go down that path we are going to wind up with *every* binary
in /usr being moved to /, which is clearly wrong.

Moving a well known, long-existing system binary is not something that
should be undertaken lightly.  I will remind everyone that when
sendmail was moved from /usr/libexec to /usr/sbin, it created 
ramifications that didn't clear up for a year.  Sendmail's move could be
justified, but I don't think chown's move can be -- certainly not on
the basis of something as flimsy as MAKEDEV needing it!

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: Speaking of moving files (Re: make world broken building fortunes )

[Ben Rosengart]

On Tue, 14 Dec 1999, Matthew Dillon wrote:

> I think at one time or another all of us have missed *something* in
> /usr that wasn't in /.  For example, disklabel -e doesn't work without
> vi -- which is in /usr.

Good example of something else that would be great to have in /bin.

*ducking*

--
 Ben Rosengart

UNIX Systems Engineer, Skunk Group
StarMedia Network, Inc.



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

Re: Speaking of moving files (Re: make world broken building fortunes )

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>
>I think at one time or another all of us have missed *something* in
>/usr that wasn't in /.  For example, disklabel -e doesn't work without
>vi -- which is in /usr.

EDITOR=/bin/ed
export EDITOR
disklabel -e

>But if we go down that path we are going to wind up with *every* binary
>in /usr being moved to /, which is clearly wrong.

Dogmatically, yes.   Sensibly:  I'm not so sure.

It would make more sense, considering the way FreeBSD is distributed for
/usr/local to be a mountpoint than for /usr to be a mountpoint.

/var is traditionally a mountpoint to keep the logs out of harms
way (and vice versa), but /usr never had that level of justification.

It is getting even less justifiable as time progress.  The last
sensible argument we had for it was the "load the filesystem from
the first 1024 cylinders or bust" problem.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: Broken sh(1): A more specific example

[Warner Losh]

In message <[EMAIL PROTECTED]> Marcel Moolenaar writes:
: #!/bin/sh
: PATH=/usr/obj/usr/src/i386/bin:/usr/obj/usr/src/i386/usr/bin:\
: /usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin:\
: /usr/games:/usr/local/bin:/usr/X11R6/bin:/home/marcel/bin ls
: ls

Isn't path not exported, so it is in effect for the first ls, but not
the second?

Warner


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

Re: Speaking of moving files (Re: make world broken building fortunes )

[David Wolfskill]

[Recipient list trimmed down to just the list.  dhw]

>Date: Tue, 14 Dec 1999 19:38:32 +0100
>From: Poul-Henning Kamp <[EMAIL PROTECTED]>

>

>It would make more sense, considering the way FreeBSD is distributed for
>/usr/local to be a mountpoint than for /usr to be a mountpoint.

It's hardly impossible for both to be mountpoints.  :-}

>/var is traditionally a mountpoint to keep the logs out of harms
>way (and vice versa), but /usr never had that level of justification.

>It is getting even less justifiable as time progress.  The last
>sensible argument we had for it was the "load the filesystem from
>the first 1024 cylinders or bust" problem.

Somehow, I'm getting a feeling of deja vu [sorry about the loss of
diacritical marks], reflecting on SunOS (both 4.x & 5.x), where /bin is
a symlink to /usr/bin, and /lib is a symlink to /usr/lib.

All of which reminds me of a singularly memorable time when I came in to
(then-)work, where I had my (personal) Sun 3/60 in use as my workstation,
and found that it had re-booted, but failed to switch to multi-user
mode.

Shortening this story, it turns out that /etc/fstab was no longer
present.  And it had been so long since I had paid any attention to the
filesystems, I didn't know what the name of the partition for /usr was.
And this was the only SunOS 4.x box in the shop.

So... I didn't have access to such user-level programs as "ls", for
example.

Shell built-ins, especially "echo", along with redirection (to fabricate
a skeleton /etc/fstab enough to get boot-strapped) saved the day... and
I learned a little.  :-}

Cheers,
david
-- 
David Wolfskill [EMAIL PROTECTED] UNIX System Administrator
voice: (650) 577-7158   pager: (888) 347-0197   FAX: (650) 372-5915


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

ESS1688 newpcm support, soundblaster panics at boot

[Andrew Gallatin]

I have an old, wheezing Dell Lattitude LM with an ESS1688 sound chip. 
(specs at http://support.dell.com/docs/systems/pespmmx/specs.htm)

I have managed to get newpcm to find the 1688 via 'options PNPBIOS'
and the following patch:

Index: sys/dev/sound/isa/sbc.c
===
RCS file: /home/ncvs/src/sys/dev/sound/isa/sbc.c,v
retrieving revision 1.7
diff -u -r1.7 sbc.c
--- sbc.c   1999/12/12 02:30:19 1.7
+++ sbc.c   1999/12/14 04:47:41
@@ -187,6 +187,7 @@
{0x0111, "Avance Asound 110"},
{0x0121, "Avance Logic ALS120"},
 
+   {0x02017316, "ESS ES1688"}, /* ESS1688 */
{0x68187316, "ESS ES1868"}, /* ESS1868 */
{0x69187316, "ESS ES1869"}, /* ESS1869 */
{0xacb0110e, "ESS ES1869 (Compaq OEM)"},



However, the machine now panics on boot in sbchan_init(), at line 821
of sb.c with a page fault on access to virtual address 0x14:
 
   810  static void *
   811  sbchan_init(void *devinfo, snd_dbuf *b, pcm_channel *c, int dir)
   812  {
   813  struct sb_info *sb = devinfo;
   814  struct sb_chinfo *ch = (dir == PCMDIR_PLAY)? &sb->pch : &sb->rch;
   815  
   816  ch->parent = sb;
   817  ch->channel = c;
   818  ch->buffer = b;
   819  ch->buffer->bufsize = DSP_BUFFSIZE;
   820  if (chn_allocbuf(ch->buffer, sb->parent_dmat) == -1) return NULL;
   821  ch->buffer->chan = (dir == PCMDIR_PLAY)? rman_get_start(sb->drq2)
   822 : rman_get_start(sb->drq1);
   823  return ch;
   824  }

I strongly suspect that this is due to the fact that this card has
only 1 dma channel.  I suspect the panic is caused by
rman_get_start(sb->drq2) when sb->drq2 is null.

Does newpcm even support simplex operations on soundblaster chips?  I
ask because I simply could not get simplex operations to work on my
wss cards, so I suspect that simplex operation is simply not well
tested.

Can anybody who is more familiar with newpcm please point me in the
right direction?  

Thanks,

Drew
--
Andrew Gallatin, Sr Systems Programmer  http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science  Phone: (919) 660-6590




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

Re: Broken sh(1): A more specific example

[Marcel Moolenaar]

Warner Losh wrote:
> 
> In message <[EMAIL PROTECTED]> Marcel Moolenaar writes:
> : #!/bin/sh
> : PATH=/usr/obj/usr/src/i386/bin:/usr/obj/usr/src/i386/usr/bin:\
> : /usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin:\
> : /usr/games:/usr/local/bin:/usr/X11R6/bin:/home/marcel/bin ls
> : ls
> 
> Isn't path not exported, so it is in effect for the first ls, but not
> the second?

Yes. The normal system default PATH applies to the second ls and it does
contain /bin. See my mail about sh's broken caching.

-- 
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking & Databases   http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]


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

Re: make world broken building fortunes

[Peter Jeremy]

On 1999-Dec-13 20:42:36 +1100, Marcel Moolenaar <[EMAIL PROTECTED]> wrote:
>Index: Makefile.inc1
>===
>RCS file: /home/ncvs/src/Makefile.inc1,v
>retrieving revision 1.106
>diff -u -r1.106 Makefile.inc1
>--- Makefile.inc1   1999/12/12 22:24:08 1.106
>+++ Makefile.inc1   1999/12/13 09:40:16
>@@ -113,7 +113,7 @@
> OBJTREE=   ${MAKEOBJDIRPREFIX}/${MACHINE_ARCH}
> .endif
> WORLDTMP=  ${OBJTREE}${.CURDIR}/${BUILD_ARCH}
>-STRICTTMPPATH= ${WORLDTMP}/bin:${WORLDTMP}/usr/bin
>+STRICTTMPPATH= ${WORLDTMP}/bin:${WORLDTMP}/usr/bin:${WORLDTMP}/usr/games
> TMPPATH=   ${STRICTTMPPATH}:${PATH}

Taking into account Sheldon and Rodney's comments, together with
another few glitches (casear is also needed to build the ROT-13
fortune database and my existing makeinfo wasn't up to building
the gawk info files), I came up with the following:

Index: src/Makefile.inc1
===
RCS file: /home/CVSROOT/src/Makefile.inc1,v
retrieving revision 1.106
diff -u -r1.106 Makefile.inc1
--- Makefile.inc1   1999/12/12 22:24:08 1.106
+++ Makefile.inc1   1999/12/13 23:07:53
@@ -113,7 +113,14 @@
 OBJTREE=   ${MAKEOBJDIRPREFIX}/${MACHINE_ARCH}
 .endif
 WORLDTMP=  ${OBJTREE}${.CURDIR}/${BUILD_ARCH}
+.if exists(${.CURDIR}/games) && !defined(NOGAMES)
+# /usr/games is needed for strfile and caesar, both of which are
+# required for building the fortune databases.
+STRICTTMPPATH= ${WORLDTMP}/bin:${WORLDTMP}/usr/bin:${WORLDTMP}/usr/games
+.else
 STRICTTMPPATH= ${WORLDTMP}/bin:${WORLDTMP}/usr/bin
+.endif
+
 TMPPATH=   ${STRICTTMPPATH}:${PATH}
 
 # bootstrap/tools make
@@ -334,7 +341,8 @@
 # tools - Build tools needed to run the actual build.
 #
 .if exists(${.CURDIR}/games) && !defined(NOGAMES)
-_strfile=  games/fortune/strfile
+# strfile and caesar are needed to build the fortune database
+_strfile=  games/fortune/strfile games/caesar
 .endif
 
 .if ${MACHINE_ARCH} == "i386" && ${MACHINE} == "pc98"
@@ -344,7 +352,7 @@
 tools::
 .for _tool in ${_strfile} ${_aout_tools} usr.bin/gensetdefs \
 gnu/usr.bin/binutils usr.bin/objformat usr.bin/yacc usr.bin/colldef \
-gnu/usr.bin/bison gnu/usr.bin/cc
+gnu/usr.bin/bison gnu/usr.bin/cc gnu/usr.bin/texinfo
cd ${.CURDIR}/${_tool}; \
${MAKE} obj; \
${MAKE} depend; \
Index: src/games/fortune/datfiles/Makefile
===
RCS file: /home/CVSROOT/src/games/fortune/datfiles/Makefile,v
retrieving revision 1.23
diff -u -r1.23 Makefile
--- Makefile1999/11/05 08:17:53 1.23
+++ Makefile1999/12/13 20:00:49
@@ -33,16 +33,13 @@
 
 .for f in fortunes fortunes2 fortunes2-o limerick startrek zippy
 $f.dat: $f
-   PATH=$$PATH:/usr/games:${.OBJDIR}/../strfile \
strfile -Crs ${.ALLSRC} ${.TARGET}
 .endfor
 
 fortunes-o.dat: fortunes-o
-   PATH=$$PATH:/usr/games:${.OBJDIR}/../strfile \
strfile -Crsx ${.ALLSRC} ${.TARGET}
 
 fortunes-o: fortunes-o.${TYPE}
-   PATH=$$PATH:/usr/games:${.OBJDIR}/../../caesar \
caesar 13 < ${.ALLSRC} > ${.TARGET}
 
 .include 


I can now successfully do a -CURRENT buildworld on a system running
-CURRENT before the signal changes.

Peter


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

FTP and PAM syslog question

[David Gillham]

I've been working with ftp and PAM lately and I noticed that
when there is no entry for ftp in pam.conf the following messages
are generated in the system logs:

Dec 14 11:04:11 frink ftpd[61865]: no modules loaded for `ftpd' service
Dec 14 11:04:11 frink ftpd[61865]: auth_pam: Permission denied

My question is, is "Permission denied" the correct error message
to use here? The first message seems fine, but the second part
seems to imply that the user was denied access. Looking through
pam_strerror.c there doesn't seem to be a good error code for
"no module entry in pam.conf" (PAM_SERVICE_ERR perhaps?). Just 
trying to avoid confusion down the line.

Thanks,
Dave



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

Re: Speaking of moving files (Re: make world broken building fortunes )

[Wilko Bulte]

On Tue, Dec 14, 1999 at 10:32:23AM -0800, Matthew Dillon wrote:
> :> 
> :> > So how about /usr/sbin/chown -> /sbin/chown so that MAKEDEV works with
> :> > just the root file system mounted?   
> :> 
> :> As one who just got his ass bitten by this, I would vote yes.
> :
> :As one who's missed chown at times when only root's mounted, I'm with Bill.
> :
> :--
> : Ben Rosengart
> :
> :UNIX Systems Engineer, Skunk Group
> :StarMedia Network, Inc.
> 
> I think at one time or another all of us have missed *something* in
> /usr that wasn't in /.  For example, disklabel -e doesn't work without
> vi -- which is in /usr.

Bad example:

yedi#EDITOR=ed disklabel -re da0
831
1,$p
# /dev/rda0c:
type: SCSI
disk: da0s2
label: 
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065

[etc]

yedi#type ed
ed is /bin/ed
yedi#

8)

-- 
Wilko Bulte Arnhem, The Netherlands   - The FreeBSD Project 
WWW : http://www.tcja.nl  http://www.freebsd.org


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

Re: Speaking of moving files (Re: make world broken building fortunes )

[Wilko Bulte]

On Tue, Dec 14, 1999 at 07:38:32PM +0100, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
> >
> >I think at one time or another all of us have missed *something* in
> >/usr that wasn't in /.  For example, disklabel -e doesn't work without
> >vi -- which is in /usr.
> 
>   EDITOR=/bin/ed
>   export EDITOR
>   disklabel -e
> 
> >But if we go down that path we are going to wind up with *every* binary
> >in /usr being moved to /, which is clearly wrong.
> 
> Dogmatically, yes.   Sensibly:  I'm not so sure.
> 
> It would make more sense, considering the way FreeBSD is distributed for
> /usr/local to be a mountpoint than for /usr to be a mountpoint.
> 
> /var is traditionally a mountpoint to keep the logs out of harms
> way (and vice versa), but /usr never had that level of justification.

It just has an historical justification. When /usr was another RK05
pack/drive.

-- 
Wilko Bulte Arnhem, The Netherlands   - The FreeBSD Project 
WWW : http://www.tcja.nl  http://www.freebsd.org


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

Re: Speaking of moving files

[Oliver Fromme]

Ben Rosengart wrote in list.freebsd-current:
 > On Tue, 14 Dec 1999, Matthew Dillon wrote:
 > 
 > > I think at one time or another all of us have missed *something* in
 > > /usr that wasn't in /.  For example, disklabel -e doesn't work without
 > > vi -- which is in /usr.
 > 
 > Good example of something else that would be great to have in /bin.

No, really bad example.

# export EDITOR=ed
# disklabel -e da0s1
759
_

Works perfectly well.  But for chown, there is no functional
equivalent in /bin or /sbin that I'm aware of.

Regards
   Oliver

-- 
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])

"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
 (Terry Pratchett)


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

Re: syscons extension: "propellers"

[Oliver Fromme]

Andrzej Bialecki wrote in list.freebsd-current:
 > On Tue, 14 Dec 1999, Donn Miller wrote:
 > > I think another way (instead of ifdefs) would be to provide some
 > > hooks into syscons, so that the "propellers" code can be loaded
 > > or unloaded via kldload/unload.

I'm not yet 100% convinced that it would make sense to separate
the propellers code into a module.  Is 5 Kbyte of kernel code
really that much of a problem?  Please note that

 1.  without the kernel option SC_PROPELLERS, none of the code
 gets compiled into the kernel.  So someone who doesn't
 need the propellers and doesn't want the 5 Kbyte "bloat"
 simply doesn't include that option in his kernel.

 2.  the option should probably not be in GENERIC.

 3.  once you have the code in your kernel, you can arbitrarily
 enable and disable (hide) the propellers.  When they're
 disabled, you get the full screen resolution back (25 rows
 or whatever).  You can even enable them on some VTYs and
 disable them on others, if you want.

So the only drawback is 5 Kbyte of kernel growth, once someone
has included the option SC_PROPELLERS.  Does this justify a
rewrite of syscons to divide it into KLDs?  Frankly, I don't
think so.

 > Another way to customize various strings, colors and variables could be
 > via sysctl. It's easy e.g. to set up the "propeller" string via sysctl.

Currently it uses ioctls, which is more appropriate for these
things, IMO.

Regards
   Oliver

-- 
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])

"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
 (Terry Pratchett)


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

Re: sysinstall: is it really at the end of its lifecycle?

[Peter Jeremy]

On 1999-Dec-14 18:36:04 +1100, Donn Miller <[EMAIL PROTECTED]> wrote:
>As far as the successor to sysinstall goes, I think it would be
>nice to have both a console version and an X version, with some X
>tookit such as Lesstif or Qt, or Tcl/Tk.

I know Jordan mentioned Qt before his over-enthusiastic hand-waving
made him over-balance, but Lesstif and Qt (or anything else related to
X11) have a number of serious problems.

Firstly, size: One of sysinstall's requirements is that it fit (along
with a variety of other related commands) onto a floppy disk.  Last
time I checked, the /stand bundle (sysinstall + friends) was ~640K.
The smallest X-server (XF86_VGA16) is 1.7MB (plus libraries).  I don't
have either Qt or Lesstif installed, but from previous dealings with
Motif, it's several times the size of the Xserver.  Unless we want to
mandate the use of ZIP drives (or similar) as FreeBSD install
floppies, we're limited to a syscons (or VTxxx) sysinstall.

The second problem is that X11 needs a fair amount of configuration
before it will work.  Whilst the VGA16 server forms a convenient
lowest-common-denominator position, it offers no real advantages over
a character-mode installation (same screen resolution and number of
colours) and significantly poorer performance.

Given the primary mission of sysinstall is to load FreeBSD, I'd
go so far as to say that developing an X version would be wasting
valuable developer resources (IMHO, of course).

Peter


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

Re: Speaking of moving files (Re: make world broken building fortunes )

[Blaz Zupan]

> How about removing awk from MAKEDEV so life isn't so hard to recover
> when you use a 3.3 fixit floppy after removing /dev and not making
> enough of it again.

How about finally starting to work on devfs and forget about all the
MAKEDEV junk and leave it as it is for now?

Blaz Zupan, [EMAIL PROTECTED], http://home.amis.net/blaz/
Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia



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

Re: sysinstall: is it really at the end of its lifecycle?

[Mike Smith]

> 
> Firstly, size: One of sysinstall's requirements is that it fit (along
> with a variety of other related commands) onto a floppy disk.  Last
> time I checked, the /stand bundle (sysinstall + friends) was ~640K.
> The smallest X-server (XF86_VGA16) is 1.7MB (plus libraries).  I don't
> have either Qt or Lesstif installed, but from previous dealings with
> Motif, it's several times the size of the Xserver.  Unless we want to
> mandate the use of ZIP drives (or similar) as FreeBSD install
> floppies, we're limited to a syscons (or VTxxx) sysinstall.

This manages to overlook the fact that the installer has to have a feed 
to a much larger source of data in order to actually perform the 
installation.

> The second problem is that X11 needs a fair amount of configuration
> before it will work.  Whilst the VGA16 server forms a convenient
> lowest-common-denominator position, it offers no real advantages over
> a character-mode installation (same screen resolution and number of
> colours) and significantly poorer performance.

You're welcome to look at the technology demonstrators currently in use 
by RedHat and Caldera if you think that this is impossible.

> Given the primary mission of sysinstall is to load FreeBSD, I'd
> go so far as to say that developing an X version would be wasting
> valuable developer resources (IMHO, of course).

It's a painful tradeoff between functionality and flash.  The latter is 
an unfortunate necessity if we are to avoid looking hopelessly outdated.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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

Re: pcm driver breakage

[D. Rock]

[Followup to myself]

With the latest changes to the pcm driver, a downgrade of channel.c to
1.8 doesn't help any more:
I cannot hear anything while playing something (in my case with mpg123).
A verbose output of mpg123 shows me that the application seems to hang
after a few write()'s to the sound device (with no sound output). There
also doesn't seem to be any interrupt activity on the pcm interrupt.

Two days before (but with rev 1.8 of channel.c) I could play any pcm file
I have with only some noise at the end if I interrupt mpg123 with ^C.

Here the latest configuration information (I can post full output if
requested).

Kernel config:
[...]
device  pcm0
device  sbc0
options PNPBIOS
[also without PNPBIOS but with
device  sbc0at isa? port 0x220 irq 5 drq 1 flags 0x10
no difference]

dmesg output from a verbose boot:
sbc0:  at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on 
isa0
pcm0:  on sbc0
pcm: setmap 3, ff00; 0xcd4b5000 -> 3
pcm: setmap 4, ff00; 0xcd4c5000 -> 4

Daniel

"D. Rock" wrote:
> 
> Hi,
> 
> something broke between rev 1.8 and 1.9 of /sys/dev/sound/pcm/channel.c
> 
> The driver probes as a:
> pcm0:  at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0
> 
> The relevant kernel config entries are
> device pcm0
> options PNPBIOS
>


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

Re: syscons extension: "propellers"

[Jordan K. Hubbard]

> I'm not yet 100% convinced that it would make sense to separate
> the propellers code into a module.  Is 5 Kbyte of kernel code
> really that much of a problem?  Please note that

I certainly wouldn't argue this based on size, no.  To understand the
point I was arguing, consider what would have been the case if the
very first screen saver had been hacked straight into syscons rather
than making it an optional component.  We'd probably have 2 or 3
screensavers at most now, each one being even more of a pain to write
than they are now since there was no standardized interface for
writing or loading screensavers (in fact, I'd have to say that our
existing interface is still pretty weak and should be something more
in AfterDark's class of abstraction if we're really seeking to do
things right, but I digress :).

So I see it with "propellers" - they're an optional feature component
and there should be a way of bolting such optional features into
syscons without having to recompile the kernel.  It's not a question
of size, it's a question of design and flexibility and I can argue
from such a purist's perspective because I'm not doing any of the work
involved and it's thus really easy to do so. :-)

- Jordan


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

Re: syscons extension: "propellers"

[Oliver Fromme]

Donn Miller wrote in list.freebsd-current:
 > Actually, that's not a bad idea.  One idea I had was combining
 > syscons with XFree86 server code, so you always have a crippled X
 > server running without the bloat of a full-blown X server
 > running.

I'm afraid that wouldn't work.  In order to run non-trivial X11
apps, you _will_ need a full-blown X server, including X libs.
You'll also need at least a very simple window manager (while
xclock would probably work without, Netscape would certainly be
pretty unusable).  Although, the window manager would be the
smallest problem of your approach...

 > One potential drawback is that it would probably bloat the
 > syscons code slightly.

*ROTFL*  :-))

Regards
   Oliver

-- 
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])

"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
 (Terry Pratchett)


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

Re: sysinstall: is it really at the end of its lifecycle?

[Mark Newton]

On Wed, Dec 15, 1999 at 07:47:00AM +1100, Peter Jeremy wrote:

 > On 1999-Dec-14 18:36:04 +1100, Donn Miller <[EMAIL PROTECTED]> wrote:
 > >As far as the successor to sysinstall goes, I think it would be
 > >nice to have both a console version and an X version, with some X
 > >tookit such as Lesstif or Qt, or Tcl/Tk.
 > 
 > I know Jordan mentioned Qt before his over-enthusiastic hand-waving
 > made him over-balance, but Lesstif and Qt (or anything else related to
 > X11) have a number of serious problems.

That's ok;  He also said it could be back-ended by TurboVision, with
the decision of which GUI to use based on whether you had a $DISPLAY
environment variable set.

 > Given the primary mission of sysinstall is to load FreeBSD, I'd
 > go so far as to say that developing an X version would be wasting
 > valuable developer resources (IMHO, of course).

Long-term, do we want the installer to be a program whose primary mission
is to load FreeBSD, or would we prefer a generic framework which provides
the situation where loading FreeBSD doesn't differ markedly from loading
(and configuring!) any particular package or subsystem after the initial
installation event?

I think I'll pick the latter.

- mark

-- 
Mark Newton   Email:  [EMAIL PROTECTED] (W)
Network Engineer  Email:  [EMAIL PROTECTED]  (H)
Internode Systems Pty Ltd Desk:   +61-8-82232999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223


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

Re: sysinstall: is it really at the end of its lifecycle?

[Daniel C. Sobral]

Peter Jeremy wrote:
> 
> Firstly, size: One of sysinstall's requirements is that it fit (along
> with a variety of other related commands) onto a floppy disk.  Last
> time I checked, the /stand bundle (sysinstall + friends) was ~640K.
> The smallest X-server (XF86_VGA16) is 1.7MB (plus libraries).  I don't
> have either Qt or Lesstif installed, but from previous dealings with
> Motif, it's several times the size of the Xserver.  Unless we want to
> mandate the use of ZIP drives (or similar) as FreeBSD install
> floppies, we're limited to a syscons (or VTxxx) sysinstall.

There is a device called cd-rom which more or less qualifies for the "or
similar" category you mention. It happens to be the most popular
installation media nowadays (though it probably comes second as far as
FreeBSD is concerned).

> Given the primary mission of sysinstall is to load FreeBSD, I'd
> go so far as to say that developing an X version would be wasting
> valuable developer resources (IMHO, of course).

X install => "user-friendly" install (perceived as) => more market share
=> more resources

--
Daniel C. Sobral(8-DCS)
who is as social as a wampas

[EMAIL PROTECTED]
[EMAIL PROTECTED]



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

Re: sysinstall: is it really at the end of its lifecycle?

[John Baldwin]

On 14-Dec-99 Peter Jeremy wrote:
> On 1999-Dec-14 18:36:04 +1100, Donn Miller <[EMAIL PROTECTED]> wrote:
>>As far as the successor to sysinstall goes, I think it would be
>>nice to have both a console version and an X version, with some X
>>tookit such as Lesstif or Qt, or Tcl/Tk.
> 
> I know Jordan mentioned Qt before his over-enthusiastic hand-waving
> made him over-balance, but Lesstif and Qt (or anything else related to
> X11) have a number of serious problems.

 [ snip ]

> Given the primary mission of sysinstall is to load FreeBSD, I'd
> go so far as to say that developing an X version would be wasting
> valuable developer resources (IMHO, of course).

Many people use sysinstall to do post-install configuration of their system,
and the seperate X interface (probably a seperate program) would be targeted at
this task.

> Peter

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


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

Re: sysinstall: is it really at the end of its lifecycle?

[Jordan K. Hubbard]

>  > I know Jordan mentioned Qt before his over-enthusiastic hand-waving
>  > made him over-balance, but Lesstif and Qt (or anything else related to
>  > X11) have a number of serious problems.
> 
> That's ok;  He also said it could be back-ended by TurboVision, with
> the decision of which GUI to use based on whether you had a $DISPLAY
> environment variable set.

Indeed, in fact using dlopen() directly from the front-end in order to
instantiate the back-end interface component gives you the option of
doing it at runtime, making the nucleus of sysinstall very small
indeed.  Of course, it would probably be linked statically with
turbovision in the single-floppy boot case, but that wouldn't stop you
from getting more clever with other installation media.

> Long-term, do we want the installer to be a program whose primary mission
> is to load FreeBSD, or would we prefer a generic framework which provides
> the situation where loading FreeBSD doesn't differ markedly from loading
> (and configuring!) any particular package or subsystem after the initial
> installation event?

The latter is, of course, not even a difficult choice to make.  We've
had the former already, been there and done that. :-)

- Jordan


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

Re: syscons extension: "propellers"

[jack]

Today Oliver Fromme wrote:

> I'm afraid that wouldn't work.  In order to run non-trivial X11
> apps, you _will_ need a full-blown X server, including X libs.
> You'll also need at least a very simple window manager (while
> xclock would probably work without, Netscape would certainly be
> pretty unusable). 

I just tried only netscape in my .xinitrc and it worked fine.  As
well as "ddd ${WINDOW_MANAGER}" or "xterm" run from .xinitrc has
for me in the past.

--
Jack O'NeillSystems Administrator / Systems Analyst
[EMAIL PROTECTED] Crystal Wind Communications, Inc.
  Finger [EMAIL PROTECTED] for my PGP key.
   PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67   FD 09 E9 3C 5F CC EB CD
   enriched, vcard, HTML messages > /dev/null
--




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

Re: sysinstall: is it really at the end of its lifecycle?

[jack]

Today Mike Smith wrote:

> > Given the primary mission of sysinstall is to load FreeBSD, I'd
> > go so far as to say that developing an X version would be wasting
> > valuable developer resources (IMHO, of course).
> 
> It's a painful tradeoff between functionality and flash.  The latter is 
> an unfortunate necessity if we are to avoid looking hopelessly outdated.

Not arguing the point in reguard to the "unwashed masses", but
when an NT[hates it]/Novell admin watched me install FreeBSD last
week his opinion of sysinstall was that it was about the cleanest
and most straight forward install program he's seen.  Guess he,
like I, is more concerned with functionality than flash.  :)

--
Jack O'NeillSystems Administrator / Systems Analyst
[EMAIL PROTECTED] Crystal Wind Communications, Inc.
  Finger [EMAIL PROTECTED] for my PGP key.
   PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67   FD 09 E9 3C 5F CC EB CD
   enriched, vcard, HTML messages > /dev/null
--




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

Re: configure problems

[Chris Piazza]

On Tue, Dec 14, 1999 at 08:24:06AM -0800, David O'Brien wrote:
> On Tue, Dec 14, 1999 at 05:00:14PM +0100, Pascal Hofstee wrote:
> > I have noticed some weird problems lately when running configure-scripts.
> > E.g. when trying to build the gtk12-port configure just hangs waiting for
> 
> Please repost this in [EMAIL PROTECTED] as that is the proper list for
> ports-related questions (which this is).
> 
> [EMAIL PROTECTED] is for issues surounding the bleading edge
> development in the base system.

It *is* a problem with freebsd-current, though.  See PR bin/15328. 

-Chris
-- 
[EMAIL PROTECTED]   [EMAIL PROTECTED]
Abbotsford, BC, Canada


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

Re: syscons extension: "propellers"

[Warner Losh]

In message <[EMAIL PROTECTED]> jack 
writes:
: I just tried only netscape in my .xinitrc and it worked fine.  As
: well as "ddd ${WINDOW_MANAGER}" or "xterm" run from .xinitrc has
: for me in the past.

Nearly all applications "work" without a window manager for some
reduced expection of "work."  Generally, the problems are restricted
to window placement and cursor differeces due to inherited cursors
from the decoration windows of X Windows.  It is certainly possible to
made these minor issues disappear with minimal effort.

Warner



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

Re: sysinstall: is it really at the end of its lifecycle?

[Warner Losh]

Personally, I like the speed of the current installation and wouldn't
want to wait for X to start.  It will triple my install setup time
since right now I'm hardware speed limited (nearly) with sysinstall.
It is much faster to draw the dialog boxes with libdialog than to
start X.

But I'm a mutant...

Warner


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

Re: sysinstall: is it really at the end of its lifecycle?

[Jordan K. Hubbard]

> Personally, I like the speed of the current installation and wouldn't
> want to wait for X to start.  It will triple my install setup time
> since right now I'm hardware speed limited (nearly) with sysinstall.
> It is much faster to draw the dialog boxes with libdialog than to
> start X.

It will always be an option, don't worry.  We're not talking about
becoming Red Hat, simply offering people more *options*. :)

- Jordan


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

Re: sysinstall: is it really at the end of its lifecycle?

[Kip Macy]

Most people I have shown the FreeBSD installer are much more impressed
with it than Redhat's snazzy GUI.

-Kip

On Tue, 14 Dec 1999, jack wrote:

> Today Mike Smith wrote:
> 
> > > Given the primary mission of sysinstall is to load FreeBSD, I'd
> > > go so far as to say that developing an X version would be wasting
> > > valuable developer resources (IMHO, of course).
> > 
> > It's a painful tradeoff between functionality and flash.  The latter is 
> > an unfortunate necessity if we are to avoid looking hopelessly outdated.
> 
> Not arguing the point in reguard to the "unwashed masses", but
> when an NT[hates it]/Novell admin watched me install FreeBSD last
> week his opinion of sysinstall was that it was about the cleanest
> and most straight forward install program he's seen.  Guess he,
> like I, is more concerned with functionality than flash.  :)
> 
> --
> Jack O'NeillSystems Administrator / Systems Analyst
> [EMAIL PROTECTED] Crystal Wind Communications, Inc.
>   Finger [EMAIL PROTECTED] for my PGP key.
>PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67   FD 09 E9 3C 5F CC EB CD
>enriched, vcard, HTML messages > /dev/null
> --
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 
> 




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

Re: sysinstall: is it really at the end of its lifecycle?

[Wilko Bulte]

On Wed, Dec 15, 1999 at 08:33:52AM +1030, Mark Newton wrote:
> On Wed, Dec 15, 1999 at 07:47:00AM +1100, Peter Jeremy wrote:

>  > Given the primary mission of sysinstall is to load FreeBSD, I'd
>  > go so far as to say that developing an X version would be wasting
>  > valuable developer resources (IMHO, of course).
> 
> Long-term, do we want the installer to be a program whose primary mission
> is to load FreeBSD, or would we prefer a generic framework which provides
> the situation where loading FreeBSD doesn't differ markedly from loading
> (and configuring!) any particular package or subsystem after the initial
> installation event?
> 
> I think I'll pick the latter.

This does, however, have all the risks of building yet another SMIT or
SAM. :-( Neither attempt at making Unix sysadm 'user-friendly' makes
me want to cheer.

And: how many people would volunteer for such a job?
Or is it assumed that since this appears suspiciously like Real Work
it will be a paid-for job?

-- 
Wilko Bulte Arnhem, The Netherlands   - The FreeBSD Project 
WWW : http://www.tcja.nl  http://www.freebsd.org


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

Re: sysinstall: is it really at the end of its lifecycle?

[Chris Costello]

On Tue, Dec 14, 1999, Donn Miller wrote:
> Maybe we could call it "sysconfig", in honor of the old
> /etc/sysconfig file that was superceded bt /etc/rc.conf.

   That's not very creative!  I had "Trident" in mind.  Only
problem is that the name is used by a company that makes video
card chips and another company that makes chewing gum.

> I saw in CUBFM (the newsgroup) where a couple of people wanted to
> do a GUI menu-based interfaced to the kernel configuration (as
> opposed to editing a file by hand).  I don't think this would be
> too hard at all, but I wondered what the experienced FreeBSD
> users thought of this idea?

   Just me.  I'm not working with anyone on this.

-- 
|Chris Costello <[EMAIL PROTECTED]>
|No program done by a hacker will work unless he is on the system.
`-


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

Re: sysinstall: is it really at the end of its lifecycle?

[Jordan K. Hubbard]

> And: how many people would volunteer for such a job?
> Or is it assumed that since this appears suspiciously like Real Work
> it will be a paid-for job?

It will be a paid-for job, naturally.

Something we also have to stay aware of in this discussion is the fact
that even if most hackers could give a fig for graphical installers
and consider them to be an unneeded bit of hand-holding, it would
still be nice to have a framework which stuff could drop into and be
accessed via a command line or turbovision type of interface.  We're
not talking about writing multiple installers for each type of UI,
after all, since that would be an unreasonable duplication of labor.
We're talking about one installation/configuration code base which can
use either X or text mode interfaces at the user's discretion, so
both "camps" get what they want.

It's also a sad fact that journalists tend to rate products based on
different criteria than engineers do, and even where we're getting kudos
in the engineering community, magazines are kicking us in the nuts over
not having something which competes head-to-head with Caldera or Red Hat.
Sad, but true.

- Jordan


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

Re: sysinstall: is it really at the end of its lifecycle?

[Chris Costello]

On Tue, Dec 14, 1999, Jordan K. Hubbard wrote:
> That's one of the design precepts of the New System, in fact.  There
> is one common UI abstraction which sysinstall II (hereafter referred
> to as Setup) and the new package system both use.  The generic UI
> front-end API is "bound" at runtime to a back-end implementation
> class, the two currently supported ones being Qt and Turbovision (the
> references implementation for the common UI stuff is all written in
> C++), and everything pops up in the appropriate UI environment from
> that point forward.  Our test code checks for $DISPLAY and does the
> appropriate Qt magic in that case, otherwise it binds in Turbovision.
> In theory, one could even write a back-end class which talked to a
> browser.  Scary. :)

   Is Qt going to be put into the base system in this case?  If
I can wrestle along with figuring out a few little problems with
Qt (ones that I could even somehow more easily solve with
Motif!), then I'll continue to develop my system administration
tool(s) with it.

   Another possible solution I was thinking about (but will
probably really regret) is keeping a binary distribution and
enabling source builds only if a Motif or Lesstif port is
installed.  Yes, this implies that I would write it in Motif.
And yes, I'm also sure that it will meet with much disagreement.

> In order to ensure that the package's installation routines call the
> common UI routines for all their interaction needs (remember the VTY2
> scenario), a package's installation script is also now assumed to be a
> secure TCL script rather than being the arbitrary executable it is
> now.  This has a number of implications even more important than
> simple interface unification, of course, most of them in the realm of
> security.

   So is all of this (TCL, Qt, et. al.) going into the base
system to facilitate this work?

-- 
|Chris Costello <[EMAIL PROTECTED]>
|A computer scientist is someone who fixes things that aren't broken.
`


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

Re: sysinstall: is it really at the end of its lifecycle?

[Ryan Thompson]

On Wed, 15 Dec 1999, Daniel C. Sobral wrote:

> Peter Jeremy wrote:
> > 
> > [...]
> > Motif, it's several times the size of the Xserver.  Unless we want to
> > mandate the use of ZIP drives (or similar) as FreeBSD install
> > floppies, we're limited to a syscons (or VTxxx) sysinstall.
> 
> There is a device called cd-rom which more or less qualifies for the "or
> similar" category you mention. It happens to be the most popular
> installation media nowadays (though it probably comes second as far as
> FreeBSD is concerned).

If memory serves, I first joined FreeBSD in 2.2.3, and I've at one point
or another ran just about every release in between, (and many more source
builds in between THOSE) up to 3.4-RC, which I'm running today on some
development/test machines.  I have made dozens of installs of FreeBSD, and
have logged a great deal of time in sysinstall on running systems.  I have
often wondered if FreeBSD would benefit from a graphical installer.

As an experienced administrator of FreeBSD on a variety of systems, new
and old, I am satisfied with the current text-based offering.

As someone who was once an inexperienced administrator of FreeBSD, I was
satisfied with the then-text-based offering.  (Which, for those of you
that don't remember, was remarkably similar to the current text-based
offering :-)

Daniel, here, sees the X install as being "user-friendly".  Is the text
based install not?  Granted, it's not the point and click interface that
windows users are accustomed to, but, clearly, if users can't navigate the
menus and manage to find their way to a help menu (and don't know how to
read install documentation)... It could be reasonably argued that they are
going to experience a rude awakening when presented with the good old root
prompt. 

>From a techical standpoint, yes, an X based install would be far too large
for a single floppy, even at the simplest level.  AND, again, as someone
who has installed FreeBSD dozens of times on various systems, I think I
should also stress that I have NEVER installed FreeBSD from CD :-)

For the average newbie "wanna try it" user, buying the CDs, books and
everything neat in a box, is more often than not the safest and simplest
route to take.  In that case, putting a graphical installer on the CD
would be a viable option.

To take this a step further, why not keep (or keep something similar to)
the current sysinstall, but have an option to fetch, install, configure
and run X and another GUI installer distribution, then start the X server
and continue the installation process from there?  The first portion of
the install (selecting media type, allocating space, and labeling) could
remain text-based, whereas the user could then be presented with a "Get X
and continue installation graphically?" option, which would then
download/copy/read a (possibly minimal) X binary distribution, small
window manager--TWM would probably suffice :-), as well as the graphical
installer.  No additional floppy storage space required. The rest of the
install, including distribution download, package install, startup config,
and all the other wonderful goodies, plus (possibly) a graphical disk
partition/labeling utility for post-install changes, would all be done
within the comfort of X, after a relatively small download/copy/read is
done from their chosen media.

Or... To take this ANOTHER small step further... For systems with enough
memory (this certainly wouldn't justify increasing the requirements), the
text installer could mount a large MFS partition to hold minimal X, window
manager and installer... Fetch automatically, do a VERY simple configure
from selected media, and continue with the install, INCLUDING a graphical
disk partitioner/labeller, after that.

Of course, with any of these options, development time and relative cost 
would be an issue, but, all things being equal, it may result in a
flexible install option that a) still runs on virtually any supported
platform, and b) gives systems with graphical support the option of a very
good looking installer :-)

> > Given the primary mission of sysinstall is to load FreeBSD, I'd
> > go so far as to say that developing an X version would be wasting
> > valuable developer resources (IMHO, of course).
> 
> X install => "user-friendly" install (perceived as) => more market share
> => more resources
> 
> --
> Daniel C. Sobral  (8-DCS)
> who is as social as a wampas
> 
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> 

---

  Ryan Thompson <[EMAIL PROTECTED]>
  50% Owner, Technical and Accounts
  Phone: +1 (306) 664-1161

  SaskNow Technologies http://www.sasknow.com
  #106-380 3120 8th St E   Saskatoon, SK  S7H 0W2




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

Re: sysinstall: is it really at the end of its lifecycle?

[Chris Costello]

On Wed, Dec 15, 1999, Peter Jeremy wrote:
> Firstly, size: One of sysinstall's requirements is that it fit (along
> with a variety of other related commands) onto a floppy disk.  Last
> time I checked, the /stand bundle (sysinstall + friends) was ~640K.
> The smallest X-server (XF86_VGA16) is 1.7MB (plus libraries).  I don't
> have either Qt or Lesstif installed, but from previous dealings with
> Motif, it's several times the size of the Xserver.  Unless we want to
> mandate the use of ZIP drives (or similar) as FreeBSD install
> floppies, we're limited to a syscons (or VTxxx) sysinstall.

   If it comes down to it, and Jordan's idea for the pkg installation
really does/can apply to the actual OS installer, what we could
do is have a statically linked, stripped, gzipped X server
(though I haven't seen how small VGA16 can be at that point), and
a small Xt frontend linked with the installer somehow (depending
on what Jordan has in mind), for those with size concerns.

   Hopefully this won't be the default for things like CDs,
however. :)

-- 
|Chris Costello <[EMAIL PROTECTED]>
|Eunuchs, the non-gender-specific OS 
`


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

Re: sysinstall: is it really at the end of its lifecycle?

[Chris Costello]

On Wed, Dec 15, 1999, Wilko Bulte wrote:
> This does, however, have all the risks of building yet another SMIT or
> SAM. :-( Neither attempt at making Unix sysadm 'user-friendly' makes
> me want to cheer.

   What do you want in making Unix quick to administer?  Seems to
me that's the real goal of those things.  Click click click done,
you know.

> And: how many people would volunteer for such a job?
> Or is it assumed that since this appears suspiciously like Real Work
> it will be a paid-for job?

   Maybe I'll get a free T-shirt for writing Trident (or whatever
name I decide on), the 'SAM Done The FreeBSD Way' project.

-- 
|Chris Costello <[EMAIL PROTECTED]>
|Managing programmers is like herding cats.
`--


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

RE: Speaking of moving files (Re: make world broken building fortunes )

[BSDman]

Poul-Henning Kamp wrote
> It would make more sense, considering the way FreeBSD is distributed for
> /usr/local to be a mountpoint than for /usr to be a mountpoint.
>
> /var is traditionally a mountpoint to keep the logs out of harms
> way (and vice versa), but /usr never had that level of justification.
>

one idea about /usr is to allow the admin to mount it read-only.
I didn't tried it but this would give some level of security against
modifications
of the files there in.

> It is getting even less justifiable as time progress.  The last
> sensible argument we had for it was the "load the filesystem from
> the first 1024 cylinders or bust" problem.

I think the "cylinder" limitation is still of concern. If all OSes come
with large root paritions, installing many of them on the same host would be
a nightmare.


Regards,

mouss

Free your Net with BSD



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

Re: sysinstall: is it really at the end of its lifecycle?

[Forrest Aldrich]

I have one request for whatever becomes of sysinstall.  And that is to 
make it technically consistent with the command line utilities capabilities.

For example, I ran into (on several different occasions) problems where
i would label a disk, allocate paritions, change parition types, etc.,
and it didn't really get done.  Doing it manually would generally resolve the
problem.

However, it's a Good Thing(tm) to have a gui of one form or another
to cater to less-experienced users.  That's just very sensible. 


Thanks.

_F


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

Re: sysinstall: is it really at the end of its lifecycle?

[George Michaelson]

Argh!!! SMIT! Hack! Puke!

Why do we have to make FreeBSD more like HP-UX? the most sucky UNIX ever
invented apart from AIX?

Those of us old enough to remember the SunView install tool with graphical
disk icons and the amazing 'free disk hog' barchart partition manager, while
finding it vaguely entertaining, could not in all concience say its a 'better'
way to install a machine. After the first 10, you generally prefer to do
something else anyway. And those icons of 5and1/4 in hard disk boxes become
so dated, I mean who is going to draw the littley bittley disk icons each
year, and are we going to wind up with skins, and will it make /. (like I care)

sysinstall is perfectly good enough as an engine.

If you want to emulate the new Anaconda Python/tk interface for Linux why
not just run it instead of re-inventing it?

Not all apps need a GUI. cat -v as a term of abuse seems to be a concept
vanishing from the language...

cheers
-George
--
George Michaelson |  DSTC Pty Ltd
Email: [EMAIL PROTECTED]|  University of Qld 4072
Phone: +61 7 3365 4310|  Australia
  Fax: +61 7 3365 4311|  http://www.dstc.edu.au




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

Re: Speaking of moving files (Re: make world broken building fortunes )

[Lyndon Nerenberg]

> "BSDman" == BSDman  <[EMAIL PROTECTED]> writes:

BSDman> one idea about /usr is to allow the admin to mount it
BSDman> read-only.  I didn't tried it but this would give some
BSDman> level of security against modifications of the files there
BSDman> in.

This is particulary useful in a lab environment where you have xx
workstations with local root, var, and swap NFS mounting an RO /usr.

--lyndon


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

MAKEDEV (Re: Speaking of moving files (Re: make world broken buildingfortunes ) )

[Andrzej Bialecki]

On Mon, 13 Dec 1999, Bill Fumerola wrote:

> On Mon, 13 Dec 1999, Louis A. Mamakos wrote:
> 
> > So how about /usr/sbin/chown -> /sbin/chown so that MAKEDEV works with
> > just the root file system mounted?   
> 
> As one who just got his ass bitten by this, I would vote yes.

On a related subject: don't you think it's high time to end up this
madness with MAKEDEV being a shell script, and reimplement it in C? Today,
MAKEDEV uses about 10 external programs, it's inflexible and complicated,
but the task it's doing could be relatively easily ported to C plus config
file. Have you ever tried to use it in nonstandad location, or on a
minimal system? The end result is usually an unpleasant surprise...

Andrzej Bialecki

//  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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

Re: sysinstall: is it really at the end of its lifecycle?

[Mark Newton]

On Tue, Dec 14, 1999 at 05:37:09PM -0600, Ryan Thompson wrote:

 > Daniel, here, sees the X install as being "user-friendly".  Is the text
 > based install not? 

Let's not get too fixated on the visual aspect of installing the OS:
That's just a sideline (an important one, but a sideline nonetheless).
There's a whole swag of structural details which the current sysinstall
fails miserably in.

For example, has anyone noticed how virtually every OS on the market
except the *BSD's build up their distributions in the same file format
and with the same package database machinations as their third-party
add-on packages?  If I'm on a Solaris box, or an IRIX box, or a SCO 
box, or a Redhat box, or essentially anything else except BSD I install
the base operating system using the same tools I'd use for any other
software.

This provides enormous benefits.  Worried about bloat?  Define what
you mean by "Base system install" at the actual time that you're installing
the system.  Don't need a nameserver?  Don't install it.  Don't need 
lpd?  Don't install it.  Do you need Fortran?  Fine, install it, even 
though it isn't part of the default installation set (h, I'm gonna
get flamed for that :-)

Upgrades are another issue:  At the moment, patching parts of the base
system is utterly hopeless.  Consider what happens whenever there's a 
security advisory:  We release a source-code patch to CERT, and say to
everyone, "Install the patch if you have the sources installed, but
if you don't have the sources you're going to have to upgrade the entire
god-damned operating system!"  And once someone has upgraded by patching
the source code, they suddenly have a "base distribution" which is 
subtly different from what would have been described as the "base 
distribution" the day before they patched it, so future bug reports become
a shot-in-the-dark type of problem.

Wouldn't it be easier to say, "pkgpatch named-8.8.2p2857" (or something -
I've pulled that example out of my butt) and have it md5 the files it's
about to replace to make sure that you have the faulty version it's
attempting to upgrade, back up the old files, install a new binary, and
patch the sources if they happen to be installed, AND RECORD THE FACT
THAT THIS HAS BEEN DONE IN THE PACKAGE DATABASE?  And if you don't like
the patch?  Back it out.

This is something other OS's find trivial:  To continue the example of
patching named, every other UNIX I can think of has named in a stand-alone
package as part of the base install.  If you want to upgrade it, you
install a more recent version of the package, and the fact that you've
done it gets recorded in a "this has been patched" section of the package
database.

Note that I haven't mentioned user-interfaces once in the discussion above:
The problems with sysinstall have very little to do with user interfaces.

 > To take this a step further, why not keep (or keep something similar to)
 > the current sysinstall, but have an option to fetch, install, configure
 > and run X and another GUI installer distribution, then start the X server
 > and continue the installation process from there? 

This discussion is orthogonal to the one we're actually happening, which
is about the structural problems in sysinstall which has lead Jordan to
place the "this has a limited lifespan" comment in the sources.  You can
do what you're proposing whether we end up with a new installer or not.

Anyway, don't think about user-interfaces -- They're the easy bit.  Re-read
Jordan's (very lucid) message on the topic from a few hours ago and think
about the problems described therein and the solutions that have been 
proposed;  you can slot your favourite user interface (even one that
looks the same as the one we're using now!) into that picture later once
the background issues have been dealt with.

   - mark

-- 
Mark Newton   Email:  [EMAIL PROTECTED] (W)
Network Engineer  Email:  [EMAIL PROTECTED]  (H)
Internode Systems Pty Ltd Desk:   +61-8-82232999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223


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

Re: Speaking of moving files

[Rodney W. Grimes]

[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> Ben Rosengart wrote in list.freebsd-current:
>  > On Tue, 14 Dec 1999, Matthew Dillon wrote:
>  > 
>  > > I think at one time or another all of us have missed *something* in
>  > > /usr that wasn't in /.  For example, disklabel -e doesn't work without
>  > > vi -- which is in /usr.
>  > 
>  > Good example of something else that would be great to have in /bin.
> 
> No, really bad example.
> 
> # export EDITOR=ed
> # disklabel -e da0s1
> 759
> _
> 
> Works perfectly well.  But for chown, there is no functional
> equivalent in /bin or /sbin that I'm aware of.

A person who really knew fsdb could do it /bin/fsdb, infact it's
not really that hard... as fsdb has chown, chgrp, chmod, chtype chname and
all the others built in as native commands ;-) :-) :-)


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: sysinstall: is it really at the end of its lifecycle?

[Andrzej Bialecki]

On Tue, 14 Dec 1999, Jordan K. Hubbard wrote:

> Something we also have to stay aware of in this discussion is the fact
> that even if most hackers could give a fig for graphical installers
> and consider them to be an unneeded bit of hand-holding, it would
> still be nice to have a framework which stuff could drop into and be
> accessed via a command line or turbovision type of interface.  We're
> not talking about writing multiple installers for each type of UI,
> after all, since that would be an unreasonable duplication of labor.
> We're talking about one installation/configuration code base which can
> use either X or text mode interfaces at the user's discretion, so
> both "camps" get what they want.

I should perhaps mention here that there are windowing GUIs out there
which are not X11. I know of two: W (almost dead, but quite sufficient),
and Microwindows (very new, still quite limited, but under active
development). Both use either VGA or VESA graphics. Both are very small
(around 100kB).

Andrzej Bialecki

//  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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

Re: MAKEDEV (Re: Speaking of moving files (Re: make world broken building fortunes ) )

[Brian Somers]

[.]
> On a related subject: don't you think it's high time to end up this
> madness with MAKEDEV being a shell script, and reimplement it in C? Today,
[.]
*cough*DEVFS*cough*
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !  <[EMAIL PROTECTED]>




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

Re: sysinstall: is it really at the end of its lifecycle?

[Chris Costello]

On Wed, Dec 15, 1999, George Michaelson wrote:
> Why do we have to make FreeBSD more like HP-UX? the most sucky UNIX ever
> invented apart from AIX?

   Is this a fact?  I always sort of liked HP-UX.  Not as fun as
FreeBSD for obvious reasons, but...

> sysinstall is perfectly good enough as an engine.

   No it's not.  Ask its author, for one.  You can read what he's
had to say about it throughout this whole thread.

> If you want to emulate the new Anaconda Python/tk interface for Linux why
> not just run it instead of re-inventing it?

   Why do everything just to be like Linux?  Who says we can't be
inventive on our own?

-- 
|Chris Costello <[EMAIL PROTECTED]>
|Drive defensively -- buy a tank.
`--


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

Re: sysinstall: is it really at the end of its lifecycle?

[Matthew Jacob]

> On Wed, Dec 15, 1999, George Michaelson wrote:
> > Why do we have to make FreeBSD more like HP-UX? the most sucky UNIX ever
> > invented apart from AIX?

Hmmph. When FreeBSD has a fully SMP-ized kernel, including filesystem and
network stacks and device drivers, and when it has something that allows
dynamic paged kernel objects and when it has a device/system configuration
manager that successfully balances persistent device names with dynamic
reconfiguration, *then* do the comparison. Until then, umm, your
underwear is showing, jack






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

Re: MAKEDEV (Re: Speaking of moving files (Re: make world broken building fortunes ) )

[Rodney W. Grimes]

> [.]
> > On a related subject: don't you think it's high time to end up this
> > madness with MAKEDEV being a shell script, and reimplement it in C? Today,
> [.]
> *cough*DEVFS*cough*

Yea... been hearing that for 4 years... one of it's big short comings is
that it needs a persistent backing store for this.  Sounds like this C
program could fullfill one of the missing parts of devfs :-)


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: MAKEDEV (Re: Speaking of moving files (Re: make world broken building fortunes ) )

[Mark Newton]

On Wed, Dec 15, 1999 at 01:39:28AM +, Brian Somers wrote:

 > [.]
 > > On a related subject: don't you think it's high time to end up this
 > > madness with MAKEDEV being a shell script, and reimplement it in C? Today,
 > [.]
 > *cough*DEVFS*cough*

Gesunteit.

   - mark

-- 
Mark Newton   Email:  [EMAIL PROTECTED] (W)
Network Engineer  Email:  [EMAIL PROTECTED]  (H)
Internode Systems Pty Ltd Desk:   +61-8-82232999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223


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

Re: Speaking of moving files

[Tony Maher]

> A person who really knew fsdb could do it /bin/fsdb, infact it's

And for everyone else ;-)

WARNING
 Use this tool with extreme caution--you can damage an FFS file system
 beyond what fsck(8) can repair.

tonym


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

Re: configure problems

[David O'Brien]

On Tue, Dec 14, 1999 at 03:06:58PM -0800, Chris Piazza wrote:
> > [EMAIL PROTECTED] is for issues surounding the bleading edge
> > development in the base system.
> 
> It *is* a problem with freebsd-current, though.  See PR bin/15328. 

That was not obvious from the email.  It still should have *started* in
[EMAIL PROTECTED]  There are probably many more on -ports@ that would
know about this problem than people on -current.

-- 
-- David([EMAIL PROTECTED])


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

Re: Speaking of moving files

[Rodney W. Grimes]

> > A person who really knew fsdb could do it /bin/fsdb, infact it's
> 
> And for everyone else ;-)
> 
> WARNING
>Use this tool with extreme caution--you can damage an FFS file system
>beyond what fsck(8) can repair.

Yea.. well...

fsdb /dev/rda0s1a
cd /dev/
cd da0s1g
chown root
chgrp wheel
chmod 640
q

There... easy enough???  fsdb is not that big of a deal as long as you
stay with the basic commands of cd, ls, chown, chmod, chgrp, rm and ln.
It's the ones like uplink downlink chgen that can hose you up but good.

If it looks like a shell command, smells like a shell command and the
man page description reads like a command it behaves pretty much like
the command.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


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

Re: sysinstall: is it really at the end of its lifecycle?

[Eric Jones]

"Jordan K. Hubbard" wrote:
> 
> > As far as the successor to sysinstall goes, I think it would be
> > nice to have both a console version and an X version, with some X
> > tookit such as Lesstif or Qt, or Tcl/Tk.  It could be a lot like
> > RedHat's "linuxconf", where you can use it as both an installer
> > or system administration tool.
> 
> Which is about correct, though there's a volume of details behind your
> conceptualization of the system in outline form there. :-)

Hear hear!  
> 
> To really understand where we're trying to go, however, it's somewhat
> helpful to take a good look at where we are now, e.g. stuck with our
> dear friends sysinstall and the pkg_install suite.
> 
[...]
> 
> We also need to discuss the ways and means of creating not so much an
> installer but an installation "nucleus" around which we also have a
> general script execution and menu-generation framework which makes it
> easy for other people to write "configurators" in secure TCL which
> take on the job of configuring some utility like, say, Samba.  When
> you pkg_add samba.zip in such a system, it runs its configurator to
> generate the initial smb.conf file but also drops a copy of the
> configuration script into some special config directory under the
> Networking category.  Now the next time the user fires up the system
> configuration tool and goes to the Networking section, they see Samba
> there as a new item and clicking on it will bring up the configuration
> tool again (perhaps in the same form, perhaps not).  If Samba is
> deleted from the system, the correspnding item goes away along with
> the configuration script and I'm sure you all get the idea at this
> point.  No more monolithic prototypes!  Framework!  Frame-work!
> Frame-work! [jkh jumps up on a chair and begins waving his hands
> enthusiastically before losing his balance and toppling over with an
> abrupt scream].
> 
> - Jordan

A worthy manifesto if ever I've seen one.  I have to add that I've been 
pretty well amused by the discussions of pretty GUI interfaces and how
they'll attract users.  My interest lies in exactly the opposite 
direction: I want to stick a floppy in and have a box find an install
server and follow a pre-defined recipe for building itself, ala
Jumpstart or Kickstart.
If I'm a Systems Administrator rolling out dozens of web 
servers or hundreds of desktops (and I frequently am), the last 
thing I want to look at is a GUI, unless it helps me to build the
configuration that'll be installed across a large base.  If anything
will drive the commercialization of FreeBSD it's manageability
enhancements.
So, when the framework, Frame-work! Frame-work! is being
considered, please keep in mind the pre-configured one disk network
install.  In the meantime, I'm off to learn what sysinstall
can do for me.  Please keep me in mind if looking for reviewers,
commentators, or (*shudder*) coders and documentors for pushing
this project forward.

Cheers,

Eric Jones
Collective Technologies


is a pretty GUI.


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

Re: sysinstall: is it really at the end of its lifecycle?

[Jordan K. Hubbard]

> My interest lies in exactly the opposite direction: I want to stick
> a floppy in and have a box find an install server and follow a
> pre-defined recipe for building itself, ala Jumpstart or Kickstart.

And you're far from alone in wanting this, another reason I've been
wanting to go to a script-based installation for some time.  It's not
at all difficult to imagine an installer which comes in two-part form:

   /stand/setup
   /stand/setup.tcl

The latter actually containing just about *all* the user interaction
and "installer behavior" that the user experiences during an
installation of FreeBSD.  That means that if you want to modify the
installer to put "Case Western University Special Custom Installation"
at the top of the first menu and add lots of distributions of purely
academic (haha) interest to the appropriate submenus, it's a simple
matter of mounting a floppy and editing a text file.  Needless to say,
this would also make translation efforts a lot easier. :-)

- Jordan


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

Re: syscons extension: "propellers"

[Kazutaka YOKOTA]

>> I'm not yet 100% convinced that it would make sense to separate
>> the propellers code into a module.  Is 5 Kbyte of kernel code
>> really that much of a problem?  Please note that
>
>I certainly wouldn't argue this based on size, no.  To understand the
>point I was arguing, consider what would have been the case if the
>very first screen saver had been hacked straight into syscons rather
>than making it an optional component.  We'd probably have 2 or 3
[...]
>So I see it with "propellers" - they're an optional feature component
>and there should be a way of bolting such optional features into
>syscons without having to recompile the kernel.  It's not a question
>of size, it's a question of design and flexibility and I can argue
>from such a purist's perspective because I'm not doing any of the work
>involved and it's thus really easy to do so. :-)

I am looking at Oliver Fromme's code. It is interesting.

I am currently preparing the final stage of syscons clean-up (which 
was outlined a year ago), and will think about reasonably generalized
way of adding extentions to syscons.

Kazu

PS: As for screen savers, there have been a plan to move screen savers
out of the kernel to userland.  A part of the necessary infrastructure
is there, but it's not fininished...


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

Re: sysinstall: is it really at the end of its lifecycle?

[Daniel C. Sobral]

Just to to correct a misunderstanding...

Ryan Thompson wrote:
> 
> Daniel, here, sees the X install as being "user-friendly".  Is the text
> based install not?  Granted, it's not the point and click interface that
> windows users are accustomed to, but, clearly, if users can't navigate the
> menus and manage to find their way to a help menu (and don't know how to
> read install documentation)... It could be reasonably argued that they are
> going to experience a rude awakening when presented with the good old root
> prompt.

Hey, I like CUI. I'd rather install with a CUI than a GUI, all other
things being equal. And besides some quirks here and there, I really
like sysinstall. So what? I'm a Forth programmer. I'm the guy who wrote
/boot/support.4th, and find it easy to read and understand, even long
after writting it. I'm the guy who wrote the builtin wrapper code in
src/sys/boot/common/interp_forth.c, though I'd prefer not to disclose
that information in public. :-)

But the fact is that when we get featured in a magazine article,
user-friendly install == GUI. No GUI, it's not an user-friendly install.
End of review. You can kick and scream all you want, that's the way it
is. Either we live by these rules, or we loose.

> >From a techical standpoint, yes, an X based install would be far too large
> for a single floppy, even at the simplest level.  AND, again, as someone
> who has installed FreeBSD dozens of times on various systems, I think I
> should also stress that I have NEVER installed FreeBSD from CD :-)

Me neither, but CD is still the most popular installation media these
days, though we, Open Source OS, probably get more network installs than
CD installs.

--
Daniel C. Sobral(8-DCS)
who is as social as a wampas

[EMAIL PROTECTED]
[EMAIL PROTECTED]


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

Re: sysinstall: is it really at the end of its lifecycle?

[Adam Strohl]

On Wed, 15 Dec 1999, Daniel C. Sobral wrote:

> Hey, I like CUI. I'd rather install with a CUI than a GUI, all other
> things being equal. And besides some quirks here and there, I really
> like sysinstall.

Its nice, but its not where it should be. 

> But the fact is that when we get featured in a magazine article,
> user-friendly install == GUI. No GUI, it's not an user-friendly install.
> End of review. You can kick and scream all you want, that's the way it
> is. Either we live by these rules, or we loose.

A VESA GUI based sysinstall replacement would probably be small enough to
fit on a floppy, yet still have the friendlyness that a new user/reviewer
would look for.

If we follow jkh's outline, making another "front end target" for the
script shouldn't be that hard.  You have X, VESA Syscons, and Text
Syscons.

The script says "ok, prompt user for ", under X it opens a window,
under Text some ASCII dialog, and under VESA a little window.

- ( Adam Strohl ) -
-  UNIX Operations/Systems   http://www.digitalspark.net  -
-  adams (at) digitalspark.netxxx.xxx. x  -
- ( DigitalSpark.NET )--- -




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

Re: RE: Speaking of moving files (Re: make world broken building fortunes )

[Matthew Dillon]

:
:Poul-Henning Kamp wrote
:> It would make more sense, considering the way FreeBSD is distributed for
:> /usr/local to be a mountpoint than for /usr to be a mountpoint.
:>
:> /var is traditionally a mountpoint to keep the logs out of harms
:> way (and vice versa), but /usr never had that level of justification.
:>
:
:one idea about /usr is to allow the admin to mount it read-only.

I tend to make /usr a separate mount point for one reason and one
reason only:  So root (/) can be made a small partition (64-128M) and 
thus be less likely to get corrupted beyond repair in a crash.

-Matt



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

Re: sysinstall: is it really at the end of its lifecycle?

[Jordan K. Hubbard]

> If we follow jkh's outline, making another "front end target" for the
> script shouldn't be that hard.  You have X, VESA Syscons, and Text
> Syscons.
> 
> The script says "ok, prompt user for ", under X it opens a window,
> under Text some ASCII dialog, and under VESA a little window.

VESA syscons, either using libvgl and an array of crude widgets or
something like MGR and its widget set, has long been on the wish-list
but I didn't even include it in my summary since it's still very much
a pipe-dream. :-)  There's actually one mode you forgot, which is
what I call "text mode", and that's straight ascii prompts, no CUI-style
dialog boxes or anything.  Think about text-to-speach devices for
the blind or serial consoles attached to really *dumb* terminals. :-)

- Jordan


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

Re: sysinstall: is it really at the end of its lifecycle?

[Tim Tsai]

> There's actually one mode you forgot, which is
> what I call "text mode", and that's straight ascii prompts, no CUI-style
> dialog boxes or anything.

  You can reprogram the character table and draw fairly nice looking menus
in text mode.  The last generations of MS-DOS based programs used them to
good effect.

  Tim


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

Re: MAKEDEV (Re: Speaking of moving files (Re: make world broken building fortunes ) )

[Warner Losh]

In message <[EMAIL PROTECTED]> Brian Somers writes:
: *cough*DEVFS*cough*

devfs*D*

Warner


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

Fallback to PIO (was: Errors from the ata disk driver)

[Greg Lehey]

On Monday, 13 December 1999 at  9:03:16 +0100, Soren Schmidt wrote:
> It seems [EMAIL PROTECTED] wrote:
>> Will the backdown to PIO mode be permanent till the next reboot of the
>> machine, or will the driver be able to attempt to return to DMA mode after
>> a timeout period.  I'm only seeing these errors under really heavy disk
>> activity (mutlitple nfs readers and writers plus rsync/mirror jobs to the
>> vinum volume in question).
>
> The fallback is permanent, but it only occurs after 3 retries on the
> failed request. If it fails 3 times in a row, there is something
> really wrong on that channel, ie bad cableing etc etc...

Wouldn't it be possible to find some way to manually reenable DMA?
Having to reboot seems rather hard.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


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

Re: FYI: Benchmarked ATA driver

[Greg Lehey]

On Saturday, 11 December 1999 at 18:55:27 +0100, Soren Schmidt wrote:
> It seems Dieter Rothacker wrote:
>> Hi,
>>
>> here I have my Bonnie++ 0.99d output:
>> machine is a P233MMX, 128MB, Hotrod66 with IBM DJNA-352500.
>> (One slice, one partition UFS)
>> --
>> Version 0.99d--Sequential Output-- --Sequential Input- --Random-
>>-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
>> Machine MB K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
>> Unknown256  6578  91 13484  71  3976  27  6539  92 13550  50 297.4   8
>>--Sequential Create-- Random Create
>>-Create-- --Stat--- -Delete-- -Create-- --Stat--- -Delete--
>>  files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
>> 30   121  83  7781  67  1079  92   135  91   184  9980  25
>> --
>> This really rocks, and the driver is perfectly stable. Very good work.
>
> Thanks, very much appreciated!!

It would be nice to see the results with a benchmark which bypasses
buffer cache, such as rawio.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


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

Re: vinum start needs block device

[Greg Lehey]

On Monday, 13 December 1999 at 18:18:14 -0500, Bill Fumerola wrote:
> On Sun, 12 Dec 1999, Peter Wemm wrote:
>
>>> -if (drive->vp->v_type != VBLK) {   /* only consider bl
>> ock devices */
>>> +if (!vn_isdisk(drive->vp)) {   /* only consider bl
>
> Note: this fixes some recent problems (Hi Greg!) that I've been
> having.

Really?  I thought they were more serious.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


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