freebsd-hackers Digest, Vol 365, Issue 3
freebsd-hac...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
or, via email, send a message with subject or body 'help' to
freebsd-hac...@freebsd.org
You can reach the person managing the list at
freebsd-ha...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-hackers digest..."
Today's Topics:
1. Re: Strange behavior of kernel module (output terminated)
(John Baldwin)
2. Another tool for updating /etc (John Baldwin)
3. Re: Strange behavior of kernel module (output terminated)
(Uffe Jakobsen)
4. Re: Unicode in Syscons: I'd like to go on (Alexander Churanov)
5. Re: Another tool for updating /etc (Garrett Cooper)
6. Re: kenv - output needed (Andrew Thompson)
7. Re: kenv - output needed (Atom Smasher)
8. Re: kenv - output needed (Garrett Cooper)
9. Re: Strange behavior of kernel module (output terminated)
(Ed Schouten)
10. Re: kenv - output needed (Andrew Thompson)
11. Re: Strange behavior of kernel module (output terminated)
(Dag-Erling Sm?rgrav)
12. Re: Unicode in Syscons: I'd like to go on (Dag-Erling Sm?rgrav)
13. Re: Strange behavior of kernel module (output terminated)
(John Baldwin)
14. Re: kenv - output needed (Atom Smasher)
15. Re: kenv - output needed (Andrew Thompson)
16. Using __attribute__((weak)) in the kernel (Patrick Mahan)
17. Re: Using __attribute__((weak)) in the kernel (Ryan Stone)
18. Re: kenv - output needed (Garrett Cooper)
19. Re: kenv - output needed (Atom Smasher)
----------------------------------------------------------------------
Message: 1
Date: Tue, 23 Mar 2010 10:00:58 -0400
From: John Baldwin <j...@freebsd.org>
Subject: Re: Strange behavior of kernel module (output terminated)
To: freebsd...@freebsd.org
Cc: Dag-Erling Sm?rgrav <d...@des.no>, Dmitry Krivenok
<kriveno...@gmail.com>
Message-ID: <20100323100...@freebsd.org>
Content-Type: Text/Plain; charset="utf-8"
On Tuesday 23 March 2010 7:22:47 am Dag-Erling Smørgrav wrote:
> Dmitry Krivenok <kriveno...@gmail.com> writes:
> > /* The function called at load/unload. */
> > static int event_handler(struct module *module, int event, void *arg)
> > {
> > int e = 0; /* Error, 0 for normal return status */
> > switch (event)
> > {
> > case MOD_LOAD:
> > uprintf("Hello FreeBSD kernel!\n");
>
> I'm not sure it's such a good idea to use uprintf() here. The event
> handler can be called in non-process context.
If you are doing a kldload post-boot it is actually done from some sort of
process context. We run module handlers synchronously from the kldload(2)
syscall.
> > int i = 0;
> > for(i = 0; i < 1000; i++)
> > {
> > uprintf("%3d ", i);
> > if(! (i % 10) ) uprintf("\n");
> > }
>
> (i % 10) is not a predicate. The test should be if (i % 10 == 0).
>
> If you want to work on FreeBSD, I recommend you get used to the
> FreeBSD coding style; see 'man 9 style'.
True, but that doesn't explain the behavior he sees.
> > As you can see the loop was terminated after i==466. I tried to
> > load/unload the module many times but the last printed number was
> > always 466.
>
> You filled up a buffer somewhere...
Does uprintf() require the caller to flush the output to the tty somehow? If
so, that seems to be a bug. Nothing in the uprintf(9) manpage suggests that
the output should be manually flushed.
--
John Baldwin
------------------------------
Message: 2
Date: Tue, 23 Mar 2010 11:08:45 -0400
From: John Baldwin <j...@freebsd.org>
Subject: Another tool for updating /etc
To: hac...@freebsd.org
Message-ID: <20100323110...@freebsd.org>
Content-Type: Text/Plain; charset="us-ascii"
I have tried a few approaches (and looked at another) for updating /etc after
world upgrades over the past several years. All of these approaches have
various tradeoffs of pros and cons. However, none of them fully fit what I
wanted:
1) Using a set of manual steps first outlined in the handbook in the pre-
mergemaster days. This involved building a new etc tree after each world
install and using a script to compare this tree to the previous tree. I
would then merge changes to /etc on the main machine by hand.
Some downsides here are that the actual merging was tedious and completely
manual. On the upside, the the necessary data was present to do a full 3-way
merge and to notice cases like a file becoming a directory, or a file being
removed.
2) Using mergemaster as described in the handbook, etc.
Some downsides here are that the process is not automated but requires manual
intervention. Using '-iFU' helps some, but you can't reliably do scripted
installs easily. MM also does not keep as much state around. The mtree db
will let you know if a file is "stock", but it doesn't have enough context to
do a 3-way merge.
3) etcmerge from ports. I have not actually used it, just read the
documentation, etc. In general this looks like it DTRT and is fairly
automated. The one caveat I see though is that it updates a separate /etc
tree that then has to be copied back only after any conflicts are resolved.
Some of the primary things I was looking for was a tool that met the
following:
1) Automated: is able to automate as much of the merging/etc. as possibly
using 3-way merges from the old and new versions of files, doing a best effort
and only requiring manual intervention for a conflict that could not be
resolved automatically. I want the ability to update 100's of machines via
scripts without having to answer prompts on each one, then getting a summary
at the end of any outstanding conflicts.
2) Best effort merge into /etc: I want the update to update as many files
directly in /etc as possible and only leave conflicts for manual resolution.
3) Doing a full 3-way merge: I want something equivalent to doing an 'svn up'
or 'cvs up'. If the local changes I made do not conflict, then just merge the
changes automatically (e.g. enabling a serial console in /etc/ttys should not
conflict with $FreeBSD$ changing when moving from 7.2 to 7.3).
To that end, I wrote a new tool that I think does a decent job of solving
these goals. It does not force you to read the diffs of any files updated in
/etc, but there are other tools available for that. However, if you are ok
with reading UPDATING, commit logs, and/or release notes for that sort of
info, then this tool may work for you.
It also has a nice feature in that you can generate a 'diff' of your current
/etc tree against the "stock" tree allowing you to easily see what local
changes you have made. I have already found this feature to be far more
useful than I first expected.
The UI is (hopefully) minimalist. The default output looks like the output of
'svn up' or 'cvs up'.
If you'd like to give it a shot, you can find the script and manpage at
http://www.FreeBSD.org/~jhb/etcupdate/ There is a README file that gives a
brief overview and instructions on how to bootstrap the needed metadata before
the first update. There is also an HTML version of the manpage.
--
John Baldwin
------------------------------
Message: 3
Date: Tue, 23 Mar 2010 16:11:58 +0100
From: Uffe Jakobsen <uf...@uffe.org>
Subject: Re: Strange behavior of kernel module (output terminated)
To: freebsd...@freebsd.org
Message-ID: <4BA8DA3E...@uffe.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 23/03/10 10.18, Dmitry Krivenok wrote:
> ....
> awk -f /sys/conf/kmod_syms.awk hello.ko export_syms | xargs -J%
objcopy %
> hello.ko
> objcopy --strip-debug hello.ko
> $ sudo make load unload
hmmmm
Try:
$ sudo make load
then wait a little and try:
$ sudo make unload
/Uffe
------------------------------
Message: 4
Date: Tue, 23 Mar 2010 19:24:33 +0300
From: Alexander Churanov <alexande...@gmail.com>
Subject: Re: Unicode in Syscons: I'd like to go on
To: Dominic Fandrey <kami...@bsdforen.de>
Cc: freebsd...@freebsd.org
Message-ID:
<3cb459ed1003230924i532...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Dominic,
Yes. Though Ed replied privately, I think It's a public information: He is
developing a syscons replacement.
I had a detailed plan on fixing the existing code, and, obviously, it is not
applicable for the new code. As I know, Ed understands Unicode and I'm sure
the new code will be done right.
Alexander Churanov
2010/3/21 Dominic Fandrey <kami...@bsdforen.de>
> On 17/03/2010 15:34, Alexander Churanov wrote:
> > Hi folks!
> >
> > Some time ago I was initiating the work on syscons driver ( see
> > http://wiki.freebsd.org/SysconsUnicodeProject ), then was too busy and
> my
> > part of the work stalled for about a year. At present I am going to
> continue
> > working on this.
> > ...
>
> Did you receive any responses to your mail?
>
> I'm kind of a unicode fan boy and I'd like to know, whether something
> is happening.
>
> Regards
>
> --
> A: Because it fouls the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?
>
------------------------------
Message: 5
Date: Tue, 23 Mar 2010 10:00:33 -0700
From: Garrett Cooper <yane...@gmail.com>
Subject: Re: Another tool for updating /etc
To: John Baldwin <j...@freebsd.org>
Cc: hac...@freebsd.org
Message-ID:
<7d6fde3d1003231000t572...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Mar 23, 2010 at 8:08 AM, John Baldwin <j...@freebsd.org> wrote:
> I have tried a few approaches (and looked at another) for updating /etc after
> world upgrades over the past several years. All of these approaches have
> various tradeoffs of pros and cons. However, none of them fully fit what I
> wanted:
>
> 1) Using a set of manual steps first outlined in the handbook in the pre-
> mergemaster days. This involved building a new etc tree after each world
> install and using a script to compare this tree to the previous tree. I
> would then merge changes to /etc on the main machine by hand.
>
> Some downsides here are that the actual merging was tedious and completely
> manual. On the upside, the the necessary data was present to do a full 3-way
> merge and to notice cases like a file becoming a directory, or a file being
> removed.
>
> 2) Using mergemaster as described in the handbook, etc.
>
> Some downsides here are that the process is not automated but requires manual
> intervention. Using '-iFU' helps some, but you can't reliably do scripted
> installs easily. MM also does not keep as much state around. The mtree db
> will let you know if a file is "stock", but it doesn't have enough context to
> do a 3-way merge.
>
> 3) etcmerge from ports. I have not actually used it, just read the
> documentation, etc. In general this looks like it DTRT and is fairly
> automated. The one caveat I see though is that it updates a separate /etc
> tree that then has to be copied back only after any conflicts are resolved.
>
> Some of the primary things I was looking for was a tool that met the
> following:
>
> 1) Automated: is able to automate as much of the merging/etc. as possibly
> using 3-way merges from the old and new versions of files, doing a best effort
> and only requiring manual intervention for a conflict that could not be
> resolved automatically. I want the ability to update 100's of machines via
> scripts without having to answer prompts on each one, then getting a summary
> at the end of any outstanding conflicts.
>
> 2) Best effort merge into /etc: I want the update to update as many files
> directly in /etc as possible and only leave conflicts for manual resolution.
>
> 3) Doing a full 3-way merge: I want something equivalent to doing an 'svn up'
> or 'cvs up'. If the local changes I made do not conflict, then just merge the
> changes automatically (e.g. enabling a serial console in /etc/ttys should not
> conflict with $FreeBSD$ changing when moving from 7.2 to 7.3).
>
> To that end, I wrote a new tool that I think does a decent job of solving
> these goals. It does not force you to read the diffs of any files updated in
> /etc, but there are other tools available for that. However, if you are ok
> with reading UPDATING, commit logs, and/or release notes for that sort of
> info, then this tool may work for you.
>
> It also has a nice feature in that you can generate a 'diff' of your current
> /etc tree against the "stock" tree allowing you to easily see what local
> changes you have made. I have already found this feature to be far more
> useful than I first expected.
>
> The UI is (hopefully) minimalist. The default output looks like the output of
> 'svn up' or 'cvs up'.
>
> If you'd like to give it a shot, you can find the script and manpage at
> http://www.FreeBSD.org/~jhb/etcupdate/ There is a README file that gives a
> brief overview and instructions on how to bootstrap the needed metadata before
> the first update. There is also an HTML version of the manpage.
Hmmm... looks pretty complete. The only [minor] concern I have is
that a lot of the variables aren't quoted, so paths with spaces will
fail (I'm not sure if this is a non-defacto standard way of installing
things in the project, but it'd be nice if these items were fixed).
I'll give it a run sometime in the near future :)...
Cheers!
-Garrett
------------------------------
Message: 6
Date: Wed, 24 Mar 2010 07:03:54 +1300
From: Andrew Thompson <tho...@FreeBSD.org>
Subject: Re: kenv - output needed
To: Atom Smasher <at...@smasher.org>
Cc: FreeBSD-Hackers <freebsd...@freebsd.org>
Message-ID: <20100323180...@citylink.fud.org.nz>
Content-Type: text/plain; charset=us-ascii
On Tue, Mar 23, 2010 at 05:12:47PM +1300, Atom Smasher wrote:
> i'm trying to figure out what might be reasonable output from kenv. on the
> three machines that i have access to i'm already seeing wide variations of
> formatting and usefulness.
>
> i'd like to collect as much output as i can get (off-list should be fine)
> from one of these two commands:
>
> 1) preferred:
> kenv | egrep bios
>
> 2) i can also use this:
> kenv | egrep 'product|maker'
kenv is essentially dumping all the variables set by the bootloader
prior to starting the kernel. If you want something more structured then
maybe the dmidecode utility would be useful.
cheers,
Andrew
------------------------------
Message: 7
Date: Wed, 24 Mar 2010 08:06:23 +1300 (NZDT)
From: Atom Smasher <at...@smasher.org>
Subject: Re: kenv - output needed
To: Andrew Thompson <tho...@FreeBSD.org>
Cc: FreeBSD-Hackers <freebsd...@freebsd.org>
Message-ID: <1003240736570.40436@smasher>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Wed, 24 Mar 2010, Andrew Thompson wrote:
> On Tue, Mar 23, 2010 at 05:12:47PM +1300, Atom Smasher wrote:
>> i'm trying to figure out what might be reasonable output from kenv. on
>> the three machines that i have access to i'm already seeing wide
>> variations of formatting and usefulness.
>>
>> i'd like to collect as much output as i can get (off-list should be
>> fine) from one of these two commands:
>>
>> 1) preferred:
>> kenv | egrep bios
>>
>> 2) i can also use this:
>> kenv | egrep 'product|maker'
>
> kenv is essentially dumping all the variables set by the bootloader
> prior to starting the kernel. If you want something more structured then
> maybe the dmidecode utility would be useful.
===============
structure is cool, but it seems like you're being human-centric in your
reference to structure; i actually want to parse the info with a script,
making kenv preferable.
i want the ability to run the script without any privileges; again making
kenv preferable.
so with an unprivileged script, i'm leaning towards kenv to find out what
hardware is running (motherboard & system info, eg "Dell Inc., 0H603H,
PowerEdge 2950" or "Acer, Navarro, Aspire 5100").
other than being formatted more nicely (for humans, anyway) and only
running with root privileges, is there any ~real~ difference between the
information i would get from dmidecode rather than kenv (as it relates to
motherboard & system make & model)? it seems like in either case, i'm just
getting the info from smbios... and that info could be good, bad or ugly
regardless of how it's formatted.
--
...atom
________________________
http://atom.smasher.org/
762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
-------------------------------------------------
"I know a lot of people without brains
who do an awful lot of talking."
-- The Scarecrow, Wizard of Oz
------------------------------
Message: 8
Date: Tue, 23 Mar 2010 12:10:52 -0700
From: Garrett Cooper <yane...@gmail.com>
Subject: Re: kenv - output needed
To: Atom Smasher <at...@smasher.org>
Cc: FreeBSD-Hackers <freebsd...@freebsd.org>, Andrew Thompson
<tho...@freebsd.org>
Message-ID:
<7d6fde3d1003231210s38e...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Mar 23, 2010 at 12:06 PM, Atom Smasher <at...@smasher.org> wrote:
> On Wed, 24 Mar 2010, Andrew Thompson wrote:
>
>> On Tue, Mar 23, 2010 at 05:12:47PM +1300, Atom Smasher wrote:
>>>
>>> i'm trying to figure out what might be reasonable output from kenv. on
>>> the three machines that i have access to i'm already seeing wide variations
>>> of formatting and usefulness.
>>>
>>> i'd like to collect as much output as i can get (off-list should be fine)
>>> from one of these two commands:
>>>
>>> 1) preferred:
>>> kenv | egrep bios
>>>
>>> 2) i can also use this:
>>> kenv | egrep 'product|maker'
>>
>> kenv is essentially dumping all the variables set by the bootloader prior
>> to starting the kernel. If you want something more structured then maybe the
>> dmidecode utility would be useful.
>
> ===============
>
> structure is cool, but it seems like you're being human-centric in your
> reference to structure; i actually want to parse the info with a script,
> making kenv preferable.
>
> i want the ability to run the script without any privileges; again making
> kenv preferable.
>
> so with an unprivileged script, i'm leaning towards kenv to find out what
> hardware is running (motherboard & system info, eg "Dell Inc., 0H603H,
> PowerEdge 2950" or "Acer, Navarro, Aspire 5100").
>
> other than being formatted more nicely (for humans, anyway) and only running
> with root privileges, is there any ~real~ difference between the information
> i would get from dmidecode rather than kenv (as it relates to motherboard &
> system make & model)? it seems like in either case, i'm just getting the
> info from smbios... and that info could be good, bad or ugly regardless of
> how it's formatted.
Are you looking for data represented similar to sysctl(8)?
Cheers,
-Garrett
------------------------------
Message: 9
Date: Tue, 23 Mar 2010 20:18:08 +0100
From: Ed Schouten <e...@80386.nl>
Subject: Re: Strange behavior of kernel module (output terminated)
To: Dmitry Krivenok <kriveno...@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID: <20100323191...@hoeg.nl>
Content-Type: text/plain; charset="us-ascii"
* Dmitry Krivenok <kriveno...@gmail.com> wrote:
> As you can see the loop was terminated after i==466.
> I tried to load/unload the module many times but the last printed number was
> always 466.
>
> Then I compiled the same module on FreeBSD-7.2 (note, the first test was run
> on 8.0).
> I saw exactly the same behavior except that the last number was always 550.
Yes. There is not a single form of flow control here, so if you can't
write more data into the TTY buffers, it will just get discarded.
FreeBSD 7 does the same thing as 8, but the default buffer sizes are
probably a bit different.
--
Ed Schouten <e...@80386.nl>
WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20100323/dc973611/attachment-0001.pgp
------------------------------
Message: 10
Date: Wed, 24 Mar 2010 08:20:39 +1300
From: Andrew Thompson <tho...@FreeBSD.org>
Subject: Re: kenv - output needed
To: Atom Smasher <at...@smasher.org>
Cc: FreeBSD-Hackers <freebsd...@freebsd.org>
Message-ID: <20100323192...@citylink.fud.org.nz>
Content-Type: text/plain; charset=us-ascii
On Wed, Mar 24, 2010 at 08:06:23AM +1300, Atom Smasher wrote:
> On Wed, 24 Mar 2010, Andrew Thompson wrote:
>
>> On Tue, Mar 23, 2010 at 05:12:47PM +1300, Atom Smasher wrote:
>>> i'm trying to figure out what might be reasonable output from kenv. on
>>> the three machines that i have access to i'm already seeing wide
>>> variations of formatting and usefulness.
>>>
>>> i'd like to collect as much output as i can get (off-list should be fine)
>>> from one of these two commands:
>>>
>>> 1) preferred:
>>> kenv | egrep bios
>>>
>>> 2) i can also use this:
>>> kenv | egrep 'product|maker'
>>
>> kenv is essentially dumping all the variables set by the bootloader prior
>> to starting the kernel. If you want something more structured then maybe
>> the dmidecode utility would be useful.
> ===============
>
> structure is cool, but it seems like you're being human-centric in your
> reference to structure; i actually want to parse the info with a script,
> making kenv preferable.
>
> i want the ability to run the script without any privileges; again making
> kenv preferable.
>
> so with an unprivileged script, i'm leaning towards kenv to find out what
> hardware is running (motherboard & system info, eg "Dell Inc., 0H603H,
> PowerEdge 2950" or "Acer, Navarro, Aspire 5100").
>
> other than being formatted more nicely (for humans, anyway) and only
> running with root privileges, is there any ~real~ difference between the
> information i would get from dmidecode rather than kenv (as it relates to
> motherboard & system make & model)? it seems like in either case, i'm just
> getting the info from smbios... and that info could be good, bad or ugly
> regardless of how it's formatted.
Yea, both methods get the info from smbios. So back to the original
question about reasonable output from kenv, I would expect it to contain
all the same basic information that dmidecode fetches. If it is missing
something then it is a bug, otherwise that is the data the bios maker
has provided and the script will need to handle it.
cheers,
Andrew
------------------------------
Message: 11
Date: Tue, 23 Mar 2010 22:07:05 +0100
From: Dag-Erling Sm?rgrav <d...@des.no>
Subject: Re: Strange behavior of kernel module (output terminated)
To: John Baldwin <j...@freebsd.org>
Cc: freebsd...@freebsd.org, Dmitry Krivenok
<kriveno...@gmail.com>
Message-ID: <86zl1y4...@ds4.des.no>
Content-Type: text/plain; charset=utf-8
John Baldwin <j...@freebsd.org> writes:
> Dag-Erling Smørgrav <d...@des.no> writes:
> > I'm not sure it's such a good idea to use uprintf() here. The event
> > handler can be called in non-process context.
> If you are doing a kldload post-boot it is actually done from some sort of
> process context. We run module handlers synchronously from the kldload(2)
> syscall.
Sure, but not when the module is loaded by the boot loader (note "can",
not "will")
> > You filled up a buffer somewhere...
> Does uprintf() require the caller to flush the output to the tty somehow? If
> so, that seems to be a bug. Nothing in the uprintf(9) manpage suggests that
> the output should be manually flushed.
I tried to read through the uprinf() code paths (into the tty layer
etc). I didn't get very far, but I discovered two things:
1) The printf() code uses uninitialized or partially-initialized
variables (grep pca)
2) There may be conditions in which tty_putchar() fails due to a buffer
filling up, though I'm not sure they apply in this particular
situation. Since uprintf() returns the number of characters actually
written, this is easy to test.
DES
--
Dag-Erling Smørgrav - d...@des.no
------------------------------
Message: 12
Date: Tue, 23 Mar 2010 22:12:46 +0100
From: Dag-Erling Sm?rgrav <d...@des.no>
Subject: Re: Unicode in Syscons: I'd like to go on
To: Alexander Churanov <alexande...@gmail.com>
Cc: Dominic Fandrey <kami...@bsdforen.de>,
freebsd...@freebsd.org
Message-ID: <86vdcm4...@ds4.des.no>
Content-Type: text/plain; charset=utf-8
Alexander Churanov <alexande...@gmail.com> writes:
> Yes. Though Ed replied privately, I think It's a public information: He is
> developing a syscons replacement.
woohoo!
DES
--
Dag-Erling Smørgrav - d...@des.no
------------------------------
Message: 13
Date: Tue, 23 Mar 2010 17:27:45 -0400
From: John Baldwin <j...@freebsd.org>
Subject: Re: Strange behavior of kernel module (output terminated)
To: "Dag-Erling Sm?rgrav " <d...@des.no>
Cc: freebsd...@freebsd.org, Dmitry Krivenok
<kriveno...@gmail.com>
Message-ID: <20100323172...@freebsd.org>
Content-Type: Text/Plain; charset="utf-8"
On Tuesday 23 March 2010 5:07:05 pm Dag-Erling Smørgrav wrote:
> John Baldwin <j...@freebsd.org> writes:
> > Dag-Erling Smørgrav <d...@des.no> writes:
> > > I'm not sure it's such a good idea to use uprintf() here. The event
> > > handler can be called in non-process context.
> > If you are doing a kldload post-boot it is actually done from some sort of
> > process context. We run module handlers synchronously from the kldload(2)
> > syscall.
>
> Sure, but not when the module is loaded by the boot loader (note "can",
> not "will")
For the purposes of writing a dummy test kld that you know you will load via
kldload it is ok though. :)
--
John Baldwin
------------------------------
Message: 14
Date: Wed, 24 Mar 2010 14:09:41 +1300 (NZDT)
From: Atom Smasher <at...@smasher.org>
Subject: Re: kenv - output needed
To: Garrett Cooper <yane...@gmail.com>
Cc: FreeBSD-Hackers <freebsd...@freebsd.org>
Message-ID: <1003241407070.40436@smasher>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Tue, 23 Mar 2010, Garrett Cooper wrote:
> Are you looking for data represented similar to sysctl(8)?
============
it doesn't quite have to be, but it is being parsed in a script.
--
...atom
________________________
http://atom.smasher.org/
762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
-------------------------------------------------
"The notion that a radical is one who hates his
country is naive and usually idiotic. He is, more
likely, one who likes his country more than the
rest of us, and is thus more disturbed than the
rest of us when he sees it debauched. He is not
a bad citizen turning to crime; he is a good
citizen driven to despair."
-- H. L. Mencken
------------------------------
Message: 15
Date: Wed, 24 Mar 2010 14:42:29 +1300
From: Andrew Thompson <tho...@FreeBSD.org>
Subject: Re: kenv - output needed
To: Atom Smasher <at...@smasher.org>
Cc: Garrett Cooper <yane...@gmail.com>, FreeBSD-Hackers
<freebsd...@freebsd.org>
Message-ID: <20100324014...@citylink.fud.org.nz>
Content-Type: text/plain; charset=us-ascii
On Wed, Mar 24, 2010 at 02:09:41PM +1300, Atom Smasher wrote:
> On Tue, 23 Mar 2010, Garrett Cooper wrote:
>
>> Are you looking for data represented similar to sysctl(8)?
> ============
>
> it doesn't quite have to be, but it is being parsed in a script.
How about pulling the kenv variables into the script.
#!/bin/sh
eval $(kenv | awk -F= '/^smbios/ { gsub("\\\.","_",$1); print $1 "=" $2}')
echo $smbios_chassis_maker
------------------------------
Message: 16
Date: Tue, 23 Mar 2010 19:35:17 -0700
From: Patrick Mahan <ma...@mahan.org>
Subject: Using __attribute__((weak)) in the kernel
To: freebsd...@freebsd.org
Message-ID: <4BA97A6...@mahan.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
All,
Has anyone used the "weak" function attribute in the kernel?
I have some modules providing APIs that I want to allow them to be either
loaded via kldload or directly built in the kernel. However, the API functions
are being referenced by code that cannot (at this time) be moved out of the
kernel. If I understand the use of the "weak" attribute, I should be able to
define these functions as "weak" and they should be over-written either by
the real code functions at kernel link or when kldload() is called.
Or am I mis-understanding the use of this attribute?
Thanks,
Patrick
------------------------------
Message: 17
Date: Tue, 23 Mar 2010 22:47:38 -0400
From: Ryan Stone <rys...@gmail.com>
Subject: Re: Using __attribute__((weak)) in the kernel
To: Patrick Mahan <ma...@mahan.org>
Cc: freebsd...@freebsd.org
Message-ID:
<bc2d971003231947j73f9...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I severely doubt that the kernel linker supports that. I believe that
the only way to accomplish what you're looking for is to leave
function pointers in the kernel that you can call, and your module can
change the function pointers at load/unload. Don't forget to have
some kind of synchronization to prevent a function pointer from being
called as it is being updated.
------------------------------
Message: 18
Date: Tue, 23 Mar 2010 19:47:52 -0700
From: Garrett Cooper <yane...@gmail.com>
Subject: Re: kenv - output needed
To: Andrew Thompson <tho...@freebsd.org>
Cc: FreeBSD-Hackers <freebsd...@freebsd.org>, Atom Smasher
<at...@smasher.org>
Message-ID:
<7d6fde3d1003231947s74b...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Mar 23, 2010 at 6:42 PM, Andrew Thompson <tho...@freebsd.org> wrote:
> On Wed, Mar 24, 2010 at 02:09:41PM +1300, Atom Smasher wrote:
>> On Tue, 23 Mar 2010, Garrett Cooper wrote:
>>
>>> Are you looking for data represented similar to sysctl(8)?
>> ============
>>
>> it doesn't quite have to be, but it is being parsed in a script.
>
> How about pulling the kenv variables into the script.
>
> #!/bin/sh
>
> eval $(kenv | awk -F= '/^smbios/ { gsub("\\\.","_",$1); print $1 "=" $2}')
>
> echo $smbios_chassis_maker
That's assuming that the there are only two tokens separated by =
though... Maybe something like the following?
eval $(kenv | awk -F= '{ gsub("\\\.", "_", $1); x= ""; for (i=1; i <=
NF; i++) { if (i > 1) { x = x "="; } x = x "" $i; } print $1 "=" $x
}')
Thanks,
-Garrett
------------------------------
Message: 19
Date: Wed, 24 Mar 2010 19:29:34 +1300 (NZDT)
From: Atom Smasher <at...@smasher.org>
Subject: Re: kenv - output needed
To: Garrett Cooper <yane...@gmail.com>
Cc: FreeBSD-Hackers <freebsd...@freebsd.org>, Andrew Thompson
<tho...@freebsd.org>
Message-ID: <1003241920390.40436@smasher>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Tue, 23 Mar 2010, Garrett Cooper wrote:
> On Tue, Mar 23, 2010 at 6:42 PM, Andrew Thompson <tho...@freebsd.org>
> wrote:
>> eval $(kenv | awk -F= '/^smbios/ { gsub("\\\.","_",$1); print $1 "=" $2}')
>>
>> echo $smbios_chassis_maker
>
> That's assuming that the there are only two tokens separated by =
> though... Maybe something like the following?
=================
even more optimistically, that assumes there's something useful stored in
smbios.chassis.version. often there isn't...
smbios.chassis.version="Chassis Version"
smbios.chassis.version="To Be Filled By O.E.M."
smbios.chassis.version="N/A"
really, the examples above are why i'm trying to collect the output of
kenv... to see what kind of garbage i'm likely to find, or even if the
garbage can even be described as "likely" (which is becoming doubtful).
--
...atom
________________________
http://atom.smasher.org/
762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
-------------------------------------------------
"Growth for the sake of growth is
the ideology of the cancer cell."
-- Edward Abbey
------------------------------
End of freebsd-hackers Digest, Vol 365, Issue 3
***********************************************