headers
Greg 'groggy' Lehey | 1 Oct 2005 06:05
Picon
Favicon

Daemon image with a beer mug?

I'm just putting the finishing touches on a paper that I'll present at
the AUUG 2005 conference (see http://www.auug.org.au/ for details).
The paper is about using FreeBSD to control the fermentation process.

Normally I put a beastie image at the bottom right of the slides (see
http://www.lemis.com/SMPng/AUUG2001/slides.pdf for an example), but in
this case it would seem appropriate to have the beastie holding a mug
of beer.  I seem to remember having seen something like that once, but
I can't trace it.  If you know where there is one, please let me know.

Greg
--
See complete headers for address and phone numbers.
Permalink | Reply | 0 comments |
headers
Peter Jeremy | 1 Oct 2005 06:08
Picon

Re: sysctl variable creation

On Fri, 2005-Sep-30 16:51:51 -0500, Eric Anderson wrote:
>I'm hacking up sys/ufs/ufs/ufs_vnops.c, and I've added a sysctl entry, 
>but it doesn't appear via sysctl -a -c vfs.ufs.  Here's what I've done:

The code looks correct but I can't find a '-c' option to sysctl in
4.x, 5.x or 7.x.  Note that SYSCTL_STRUCT defines an opaque type that
won't be displayed by default.  You may want "sysctl -x vfs.ufs"

--

-- 
Peter Jeremy
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 1 comment |
headers
Eric Anderson | 1 Oct 2005 06:14
Favicon

Re: sysctl variable creation

Peter Jeremy wrote:
> On Fri, 2005-Sep-30 16:51:51 -0500, Eric Anderson wrote:
> 
>>I'm hacking up sys/ufs/ufs/ufs_vnops.c, and I've added a sysctl entry, 
>>but it doesn't appear via sysctl -a -c vfs.ufs.  Here's what I've done:
> 
> 
> The code looks correct but I can't find a '-c' option to sysctl in
> 4.x, 5.x or 7.x.  Note that SYSCTL_STRUCT defines an opaque type that
> won't be displayed by default.  You may want "sysctl -x vfs.ufs"
> 

Yea, that's what I meant, sorry about that.  I think I am missing a 
SYSCTL_DECL in there, so maybe this would work:

--- /usr/src/sys/ufs/ufs/ufs_vnops.c-orig       Thu Sep 29 20:47:50 2005
+++ /usr/src/sys/ufs/ufs/ufs_vnops.c    Fri Sep 30 23:14:34 2005
 <at>  <at>  -79,6 +79,7  <at>  <at> 
  #include <ufs/ufs/dir.h>
  #include <ufs/ufs/ufsmount.h>
  #include <ufs/ufs/ufs_extern.h>
+#include <ufs/ufs/ufsstats.h>
  #ifdef UFS_DIRHASH
  #include <ufs/ufs/dirhash.h>
  #endif
 <at>  <at>  -122,6 +123,13  <at>  <at> 
         0, DIRBLKSIZ - 12, 2, ".."
  };

+struct ufsstats ufsstats;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Stacey | 1 Oct 2005 11:16
Favicon

Re: serial login to SBC

Reference:
> From:		<jerry <at> evasefor.com> 
> Date:		Fri, 30 Sep 2005 17:14:01 +0200 
> Message-id:	<0MKoyl-1ELMcD46br-0004FY <at> mrelay.perfora.net> 

jerry <at> evasefor.com wrote:
> 
> Hello list,
> I am trying to use a FreeBSD box to log into a Single Board Computer. I
> have a null modem and it's plugged to both serial
> ports. The SBC runs openbsd ( /dev/cua00).
> When I run "cu -l /dev/cuaa0" from FreeBSD, I don't get any login
> prompt. 
>  
> What I am doing wrong? 

Use a break out box, look at the LEDs,
see if all the CTS RTS DTR DCE tedious stuff is set right.

> 
> I've already read the FBSD handbook.
> I have an OpenBSD box to experiment with first, and can't serial login
> either.
> I really need help on this one.

--

-- 
Julian Stacey.  Consultant Unix Net & Sys. Eng., Munich.  http://berklix.com
Mail Ascii not HTML.          Ihr Rauch = meine allergischen Kopfschmerzen.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Antoine Pelisse | 1 Oct 2005 15:56
Picon
Gravatar

Re: freebsd-5.4-stable panics

On 9/30/05, John Baldwin <jhb <at> freebsd.org> wrote:
>
> On Friday 30 September 2005 11:25 am, Antoine Pelisse wrote:
> > On 9/30/05, John Baldwin <jhb <at> freebsd.org> wrote:
> > > On Friday 30 September 2005 05:24 am, Antoine Pelisse wrote:
> > > > Hi Robert,
> > > > I don't think your patch is correct, the total linked list can be
> > > > broken
> > > >
> > > > while the lock is released, thus just passing the link may not be
> > > > enough I have submitted a PR[1] for this a month ago but nobody took
> > > > care of it yet Regards,
> > > > Antoine Pelisse
> > > >
> > > > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84684
> > >
> > > I think this patch looks ok. Robert, can you get the original panic on
> > > this
> > > thread tested against this patch?
> >
> > I had a small program which could reproduce this panic in 10 seconds, it
> > was basically creating empty threads and calling kvm_getprocs() in the
> same
> > time. Anyway the patch was able to stop the program from panicing.
> > The panic is also reproducible in RELENG_6 and HEAD IIRC.
>
> It turns out that the sysctl buffer is already wired in one of the two
> cases
> that this function is called, so I moved the wiring up to the upper layer
> in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yar Tikhiy | 1 Oct 2005 21:35
Picon

Re: A smarter mergemaster

On Fri, Sep 30, 2005 at 02:37:05PM -0700, Kevin Oberman wrote:
> 
> You just hit on one of my pet peeves with mergemaster! Contrary to what
> you say: "every single default for mergemaster is to do nothing", when a
> file is found in /etc/rc.d that is not in /usr/src/etc/rc.d, the default
> is to delete the file in etc. I think that this is a bad thing(tm). I
> have to restore my profile.sh (which MUST be in /etc/rc.d as it needs to
> be run before /usr is mounted).
> 
> I do have an open PR on this (conf/85449), but it does not seem to have
> gone anywhere other than being assigned to you last Friday. (No, I
> didn't expect anything to happen this quickly. You just gave me such a
> perfect opportunity to gripe!)

FWIW, I wondered if my version of mergemaster in p4 was affected
by this issue and found to my surprise that I had already addressed
it in my changes.

--

-- 
Yar
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Doug Barton | 1 Oct 2005 21:42
Picon
Favicon

Re: A smarter mergemaster

Kevin Oberman wrote:
>>Date: Thu, 29 Sep 2005 23:41:57 -0700
>>From: Doug Barton <dougb <at> FreeBSD.org>
>>Sender: owner-freebsd-current <at> freebsd.org
>>
>>One of the design decisions that you need to be aware of for this project
>>since day one was to try and balance intelligent behavior and configuration
>>options that would be useful for the very small percentage of the FreeBSD
>>user community that constitutes our developers, versus the needs of the vast
>>majority of "regular" users who need to be able to use the tool without
>>becoming experts in either our build system, or the tool itself. That is why
>>every single default for mergemaster is to do nothing. It was a purposeful
>>decision to require the user to examine change requests, and make an
>>affirmative choice to approve them.
> 
> 
> Doug,
> 
> You just hit on one of my pet peeves with mergemaster! Contrary to what
> you say: "every single default for mergemaster is to do nothing", when a
> file is found in /etc/rc.d that is not in /usr/src/etc/rc.d, the default
> is to delete the file in etc. I think that this is a bad thing(tm).

Agreed, The only thing I can think of as a reason for the anomaly is that at
the time I wrote that code, the problems being reported with stale rc files
were pretty numerous, and perhaps I was being overzealous.

I've already said that I like Yar's idea of offering options to delete files
or not, so I'll look at bringing at least that code in ASAP with the change
that you requested, and possibly seek an MFC before 6 release.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bakul Shah | 1 Oct 2005 22:34

Re: A smarter mergemaster

Here is an idea for the mergemaster hackers' consideration!

By keeping /etc files in a source repository one can archive
and document all local changes.  This is useful for some of
the same reasons for which we keep sources in a repo:
recovery from mistakes, reuse of old code, checking who did
what, more than one person can make changes, tracking
history, debugging etc.

If mergemaster handled or worked with a local cvs /etc repo
that'd be very nice!  The idea is to make changes and test
them in a temp workspace and commit them *only if they do the
right thing*!  I envision a workflow something like this
(using make for illustration purposes):

cd <etc workspace>
make etc-diff	# ensure your workspace reflects what is in /etc
<if resync is needed, commit them to local repo>

make import	# import the latest /usr/src/etc into etc workspace
make diff	# look over the changes
<make any local repairs>
make install	# install to /etc; do mkdb etc.
<check out your changes>

Finally:
make commit	# commit changes to local repo
OR
make undo	# if things didn't quite work, restore /etc to old state.
(Continue reading)

Permalink | Reply | 3 comments |
headers
M. Warner Losh | 1 Oct 2005 22:58

Re: A smarter mergemaster

In message: <200510012034.j91KYWPQ064132 <at> gate.bitblocks.com>
            Bakul Shah <bakul <at> BitBlocks.com> writes:
: Here is an idea for the mergemaster hackers' consideration!
: 
: By keeping /etc files in a source repository one can archive
: and document all local changes.  This is useful for some of
: the same reasons for which we keep sources in a repo:
: recovery from mistakes, reuse of old code, checking who did
: what, more than one person can make changes, tracking
: history, debugging etc.
: 
: If mergemaster handled or worked with a local cvs /etc repo
: that'd be very nice!  The idea is to make changes and test
: them in a temp workspace and commit them *only if they do the
: right thing*!  I envision a workflow something like this
: (using make for illustration purposes):
: 
: cd <etc workspace>
: make etc-diff	# ensure your workspace reflects what is in /etc
: <if resync is needed, commit them to local repo>
: 
: make import	# import the latest /usr/src/etc into etc workspace
: make diff	# look over the changes
: <make any local repairs>
: make install	# install to /etc; do mkdb etc.
: <check out your changes>
: 
: Finally:
: make commit	# commit changes to local repo
: OR
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Meyer | 1 Oct 2005 23:10
X-Face

Re: A smarter mergemaster

In <200510012034.j91KYWPQ064132 <at> gate.bitblocks.com>, Bakul Shah <bakul <at> BitBlocks.com> typed:
> Here is an idea for the mergemaster hackers' consideration!
> 
> By keeping /etc files in a source repository one can archive
> and document all local changes.  This is useful for some of
> the same reasons for which we keep sources in a repo:
> recovery from mistakes, reuse of old code, checking who did
> what, more than one person can make changes, tracking
> history, debugging etc.

Yup. I've been doing that for about a decade. It also makes a nice
tool for disaster recovery. Rather than backing up all the
FreeBSD-supplied softare, I back up the repository. After a disk loss,
I pull the original install disks, reinstall, then check out the
config files from the repository.

> If mergemaster handled or worked with a local cvs /etc repo
> that'd be very nice!  The idea is to make changes and test
> them in a temp workspace and commit them *only if they do the
> right thing*!  I envision a workflow something like this
> (using make for illustration purposes):

It really ought to provide hooks of some kind for dealing with the
repository, rather than having CVS wired into it, as some of us prefer
newer tools to CVS. But that's a minor detail.

	<mike
--

-- 
Mike Meyer <mwm <at> mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane