* Re: [RFC] make PC Speaker driver work on x86-64
From: Matthieu CASTET @ 2006-04-29 21:00 UTC (permalink / raw)
To: linux-kernel; +Cc: discuss
In-Reply-To: <200604291830.k3TIUA23009336@harpo.it.uu.se>
Hi,
Le Sat, 29 Apr 2006 20:30:10 +0200, Mikael Pettersson a écrit :
>
> Is there a better way to do this? ACPI?
>
Yes, I believe using PNP layer (that use ACPI with pnpacpi) with PNP0800
will be cleaner.
Matthieu
^ permalink raw reply
* grub-emu state of the art
From: Eric Salomé @ 2006-04-29 21:00 UTC (permalink / raw)
To: 'The development of GRUB 2'
In-Reply-To: <878xpoi1ez.fsf@xs4all.nl>
Hi,
I need a working grub-emu to continue the port of a system of my own
from grub to grub 2.
I am currently working on a i386 pc and had hard time the first days
with the 1.93 delivery : grub-emu would run (on Linux based Ubuntu OS)
and come with a rescue mode prompt, but was not likely to load and init
modules such as "normal.mod" (even by hand).
Am I doing something wrong or is it the current state of grub-emu ?
In the latter case, I'd be glad to help a little and see what can be
done to have a fully functional grub-emu.
Best regards.
_________________________________________
Eric Salomé - Paris, France
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: Jakub Narebski @ 2006-04-29 20:58 UTC (permalink / raw)
To: git
In-Reply-To: <7viros1585.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> * "prior" - heads that represent topic branch merges
>
> This is not any different from usual "parent" at all (but you
> have to think about it a bit to realize it).
[cut]
Thanks for an explanation.
I would say that "prior" is not THAT different from usual "parent",
rather than it is not ANY different.
My doubts about recording previous head of a "union" (pu-like) branch
is that for merge (e.g. 'pu' to 'next', cherrypick to/from 'pu', 'pu'
rebase) is that for merge algorithm all parents are equivalent, with
eventual exception of first which can be treated special ('ours').
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: PROBLEM: ramfs reports 0 free
From: Willy Tarreau @ 2006-04-29 20:50 UTC (permalink / raw)
To: Senior Goat; +Cc: linux-kernel
In-Reply-To: <BAY101-F3554D73ACD8CD3AFCF5D8081B30@phx.gbl>
On Sat, Apr 29, 2006 at 07:52:16PM +0000, Senior Goat wrote:
> [1.] One line summary of the problem:
>
> ramfs erroneously reports 0 bytes free, which confuses some programs.
>
> [2.] Full description of the problem/report:
>
> The system call on a mounted ramfs, as indicated by df, reports 0
> bytes total, used, and free. If ramfs is expected to perform like a
> filesystem, it should not do this.
(...)
> [X.] Other notes, patches, fixes, workarounds:
>
> I read that Linus himself wrote this module. For some reason he
> decided to report 0, but I can't figure why. Perhaps the overhead for
> finding information was too great.
>
> Couldn't you add up the amount of filesystem cache with the free memory
> and get a crude, but quick estimate of the amount of free space available
> for any given ramfs.
>
> I'm not sure how to handle the total space, since you probably don't
> want that fluctuating too much, except that you might just report the
> total amount of ram(which won't fluctuate), and then report the used ram.
> This is all information that /free/ reports from system calls with little
> delay.
>
> The only other place I can think that ramfs might get memory is when the
> kernel swaps out other processes, but you can't count on that.
>
> To sum it up, the best way to get a semi-valid report would be:
> total: total ram
> used: used ram (which takes into account memory used in the ramfs,
> coincidentally)
> free: total - used (which ignores disk cache, since that should be
> freed when needed)
To achieve this, you have to set an arbitrary limit on the maximal FS size.
I have updated a patch originally from David Gibson to enforce limits on
RAMFS. His original patch for 2.4.19-rc1-ac2 as well as my update for
2.4.32 is available here, in case you're interested in porting it to 2.6 :
http://w.ods.org/linux/kernel/2.4/lkup/ramfs-limit.html
> The other option would be to make all the little programs (like
> Debian's package manager) check if the filesystem it wants to write to is
> a ramfs before reporting an error, but this is a blatant hack.
This is very hard to maintain, that's why I include the patch above in
my kernels ;-)
Cheers,
Willy
^ permalink raw reply
* Re: Problem between autofs 3 and autofs4
From: ergatz @ 2006-04-29 20:55 UTC (permalink / raw)
To: autofs mailing list
Ian,
Thanks for your responses. I wanted to let you know that the rpm that I
installed is version 4.1.3-169. It may have been fixed in an earlier iteration,
but this is the one downloaded.
dorothy
-------------- Original message ----------------------
From: Ian Kent <raven@themaw.net>
> On Sun, 23 Apr 2006, ergatz@comcast.net wrote:
>
> > I tried all sorts of things, to include autofs reload, autofs stop and start,
> ypbind stop and start.
> > The only thing that would work was too reboot the machine. Rebooting a SERVER
> is not
> > really something I want to do when I make changes.
>
> Oh and you think I don't realize that!
>
> >
> > One of the guys in the office found an updated version of autofs. I installed
> it, and everything
> > works like a charm.
>
> What version?
>
> >
> > A commentary: I found somewhere that autofs 4 was written by someone who did
> not write
> > autofs3. In fact, the author of 3 said he would like to come back to write 5.
> It seems the author
> > of 4 did not know as much about autofs as he should have to write properly
> functioning code.
>
> Who are you talking about.
> All this happened a very long time ago.
>
> Perhaps "me" since I took over the v4 maintenance several years ago and
> 4.1.3 is one of my releases.
>
> The fact is that what you have should work and if it's been broken by the
> addition of a patch then we need to identify which patch that is.
>
> You should also consider the fact that changes to the package are often
> driven by requests for functionality on this list. I don't always get that
> right but I try.
>
> You might also have a look at the CHANGELOG in 4.1.4.
> The list of bugs fixed is so long that I didn't have any time to work on
> developing things that really need doing.
>
> Previous to my current job at RedHat I worked as an infrastructure analyst
> at a Solaris site. Very demanding of time as you likely realize and then
> would go home and try to work on autofs.
>
> That was really hard.
>
> >
> > Just one of my many frustrations with RedHat and open source....
>
> How is RedHat responsible for my mistakes?
>
> Another fact is that there are many devoted people at RedHat that try to
> fix breakage in my packages (including me) and they have a difficult time
> to be sure.
>
> On a lighter note I must apologize (to everyone) for not being more
> helpful on the list lately but I'm heavily focused on version 5
> development (which no doubt will not work properly either, ha).
>
> Ian
>
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs
^ permalink raw reply
* Re: netboot related projects
From: Yoshinori K. Okuji @ 2006-04-29 20:54 UTC (permalink / raw)
To: The development of GRUB 2
In-Reply-To: <878xpoi1ez.fsf@xs4all.nl>
On Saturday 29 April 2006 22:15, Marco Gerards wrote:
> vincent guffens <v.guffens@imperial.ac.uk> writes:
>
> Hi Vincent,
>
> > I just wanted to let you know that I contacted the maintainer of
> > Etherboot to inform him of my current attempt to port the etherboot
> > drivers to grub2.
>
> Is he willing to cooperate with us so it will be easier to share code?
> I think I once sent him an email about it... But I am not sure
> anymore. :-)
Honestly, I don't like to copy Etherboot's drivers to GRUB any longer. I
rather consider how to use the UNDI interface provided by Etherboot. When I
worked on netboot in GRUB Legacy, Etherboot didn't support UNDI, so I had to
copy the drivers. According to him, the current Etherboot supports UNDI, so
it should be feasible to use Etherboot's drivers via UNDI.
I think the difficulty is the case where GRUB is not loaded by Etherboot, for
example, when GRUB boots from a disk directly. In this case, one way would be
to hack Etherboot so that Etherboot can be invoked by GRUB and give the
control back to GRUB.
From the experience of GRUB Legacy, I know how painful to synchronize code
with an external project, so I'd like to investigate this direction.
Okuji
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: Junio C Hamano @ 2006-04-29 20:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e30b48$ovk$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> * "prior" - heads that represent topic branch merges
This is not any different from usual "parent" at all (but you
have to think about it a bit to realize it).
Before talking about making a new commit object that links to
other related commits, let's first talk about what it means to
update the branch head ($GIT_DIR/refs/heads/<branch>) from
commit A to commit B. Understanding what it means is more
fundamental.
A git "branch" points at the tip of one possible history of a
development. As the often-used word "topic branch" tells you, a
"branch", i.e. that history, has a specific purpose. The
purpose of my "master" branch is to give reasonably stable new
feature set and bugfixes, "next" to give testable ones, and "pu"
to collect remaining bits that are worthy of discussion.
When your branch head points at commit A and you update the head
to point at a different commit B, you are making this statement:
The commit B suits the purpose of the branch better
than the commit A.
Notice there may or may not be ancestry relation between these
two commits at this point of the discussion. B may be a direct
child of commit A, a merge that has A as its first parent, a
merge that has A as its one of its parent (but not necessarily
the first), or a Nth-generation descendant if the update was a
fast forward merge from another branch. It might even be an
ancestor if the update rewinds the history.
Among the above cases (and there may be others), in only two
cases you actually create a new commit to record that
statement [*1*].
The simplest case is when commit B is a direct, single-parent
child of commit A, and that statement is in your commit log
message. "I started out from the commit A, and the result is
this tree. The result suits what I am doing better than the
previous commit and I made the world a better place." -- the "I
started out from the commit A" part is on the parent header and
the rest is in the free-text.
When you are creating a merge of N parents, the principle is the
same. Although in pure core-git terms all parents are equal, in
practice, the first parent has somewhat special meaning to you.
When the parents of commit B are A and X, you started out from
the commit A. Then what are other parents? You can read such a
commit this way:
I started out from commit A and came up with this tree,
which suits my purpose better. While doing so, I have
also considered what X has; and this result, commit B,
suits my purpose better than X, too.
This is why a later merge with another branch that further
builds on top of X works so well.
----A----B
/
----X----Y
If somebody built Y on X independently from us, when we merge
with Y, we say the merge base is X because B says "I've already
considered what X has" to do a 3-way merge. While that is what
happens at the mechanical level, what is happening at the
philosophical level is we are taking "I consider that B is
better than X", part of the message seriously, which means "I
want to keep changes I made between X B". Also the other person
who made Y made a similar statement that she considers Y is
better than X, and we try to preserve the changes between X and
Y in the automated part of the merge while preparing the tree to
commit the merge between B and Y.
Once you start reading the commit parent to mean " considering
what all of these commits have, what this new commit has suits
my purpose better", it becomes clear that the "previous" pointer
for a branch like my "pu" is just another "parent".
I rebuild "pu" from the tip of then-current "next", and merge
other topics in, and discard the previous "pu". So it results
in this kind of graph:
o---o---o---o---o (updated "pu")
/ / / /
---o---o---o---o
\ \ \ \ \
o---------------o---o---o---o (previous "pu")
But theoretically, I could include the previous "pu" tip as one
of the parents of the updated "pu" branch.
At the mechanical level, I start from then-current "next" and
merge each topic branch one-by-one on top of it. But at the
philosophical level, what I am doing is to publish material that
shows a set of proposed changes that are more appropriate for
review by the curious than the previous round of "pu" head used
to have. So the previous "pu" _is_ in the consideration while I
publish the updated "pu", although it is _not_ recorded anywhere.
After I come up with a fully merged tree, I could make a fake
Octopus that has the previous "pu" as its first parent and each
of the topic branch heads merged as second and subsequent
parents, with the resulting tree. That would be more "honest"
at the philosophical level.
I am not going to actually suggest anybody doing this as a good
practice, but we can make such a commit with the current tool
like this:
git checkout pu
git tag -f prev-pu ;# remember where we were
git reset --hard next ;# start at next
git pull . topic-1 ;# merge all remaining topics
git pull . topic-2 ;# ...
git pull . topic-3
...
git tag -f next-pu ;# this tree is what we want
git reset --hard prev-pu ;# start from previous
git pull --no-commit -s ours . next topic-1 topic-2 ...
git read-tree -m -u next-pu ;# record a merge whose first
git commit ;# parent is previous pu and
;# has all the topics merged.
[Footnote]
*1* IOW, we _are_ losing some information by not recording the
fact that fast-forward was done while doing so.
That record should _not_ be in the commit chain. At the
mechanical level, recording that in the commit chain means two
criss-crossing branches never converge at the commit chain
level, which is already bad. At the philosophical level, the
commit chain is a mesh of many possible "global" histories, and
the record that somebody (a particular branch in a particular
repository) was at what point in the mesh at given time does not
belong there.
But from the repository-owner's point of view, that _might_ be a
useful information to keep. I am just saying this preemptively
so that if somebody wants to record it, that should not be
recorded in the commit object.
^ permalink raw reply
* Re: [RFC] make PC Speaker driver work on x86-64
From: Jeff Garzik @ 2006-04-29 20:36 UTC (permalink / raw)
To: Mikael Pettersson; +Cc: discuss, linux-input, linux-kernel, Andrew Morton
In-Reply-To: <200604291830.k3TIUA23009336@harpo.it.uu.se>
Mikael Pettersson wrote:
> I have a pair of Athlon64 machines that dual-boot 32-bit and
> 64-bit kernels. One annoying difference between the kernels
> is that the PC Speaker driver (CONFIG_INPUT_PCSPKR=y) only
> works in the 32-bit kernels. In the 64-bit kernels it remains
> inactive and doesn't even generate any boot-time initialisation
> or error messages.
>
> Today I debugged that issue, and found that the PC Speaker
> driver's ->probe() routine doesn't even get called in the
> 64-bit kernels. The reason for that is that the arch code
> apparently has to explictly add a "pcspkr" platform device
> in order for the driver core to call the ->probe() routine.
> arch/i386/kernel/setup.c unconditionally adds a "pcspkr"
> device, but the x86_64 kernel has no code at all related to
> the PC Speaker.
Wow, thanks.
I was wondering why my PC speaker didn't seem to work. And here I was,
blaming Fedora...
Jeff
^ permalink raw reply
* Get ahead in life! rumrf
From: Tameka Swan @ 2006-04-29 20:35 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <717301c668e2$71aefea4$220ca16e@2xshzc1>
Genuine College Degree in 2 Weeks!
(831) 603-4625 Call Now and leave us message
Have you ever thought that the only thing stopping you from a
a great j0b and better pay was a few letters behind your name?
Well now you can get them!
BA BSc MA MSc MBA PHD
Within 2 weeks!
No Study Required!
100% Verifiable
(831) 603-4625 Call Now and leave us message
These are real, genuine degrees that include Bachelors, Masters
and Doctorate degrees. They are verifiable and student records and
transcripts are also available. This little known s.ecret has been
kept quiet for years. The opp0rtunity exists due to a lega.l loophole
allowing some established colleges to award degrees at their discretion.
With all of the attention that this news has been generating, I wouldn't
be surprised to see this loophole closed very soon.
Call n0w for more information today, you'll thank me later...
(831) 603-4625 Call Now and leave us message
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: Pekka Enberg @ 2006-04-29 20:35 UTC (permalink / raw)
To: David Gómez; +Cc: David Vrabel, Francois Romieu, Linux-kernel, netdev
In-Reply-To: <20060429122119.GA22160@fargo>
Hi David,
On Sat, 2006-04-29 at 14:21 +0200, David Gómez wrote:
> I already had it modified, just needed to create the patch... Anyway,
> have you submitted it to netdev?
No, I haven't. I don't have the hardware, so I can't test the driver.
Furthermore, there's plenty of stuff to fix before it's in any shape for
submission. If someone wants to give this patch a spin, I would love to
hear the results.
Pekka
^ permalink raw reply
* [ALSA - driver 0002085]: No sound with Benq JB S52
From: bugtrack @ 2006-04-29 20:33 UTC (permalink / raw)
To: alsa-devel
The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2085>
======================================================================
Reported By: antoniotorres
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 2085
Category: PCI - intel8x0
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution: Ubuntu 5.10
Kernel Version: 2.6.16 with beyond2 patches
======================================================================
Date Submitted: 04-29-2006 22:33 CEST
Last Modified: 04-29-2006 22:33 CEST
======================================================================
Summary: No sound with Benq JB S52
Description:
There's no sound either with latest alsa version. I've played with
alsamixer with no luck.
At tuxmobil.org there's one entry with a Benq S53 (similar to mine) with
same behaviour.
Help is appreciated.
Thanks.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
04-29-06 22:33 antoniotorres New Issue
04-29-06 22:33 antoniotorres Distribution => Ubuntu 5.10
04-29-06 22:33 antoniotorres Kernel Version => 2.6.16 with beyond2
patches
======================================================================
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* Re: [PATCH 10/12] fbdev: Static pseudocolor with depth less than 4 does exist
From: Brad Boyer @ 2006-04-29 15:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Antonino A. Daplas, Linux Frame Buffer Device Development,
Andrew Morton, Linux/m68k
In-Reply-To: <Pine.LNX.4.62.0604292025410.4557@pademelon.sonytel.be>
On Sat, Apr 29, 2006 at 08:28:37PM +0200, Geert Uytterhoeven wrote:
> On the other hand, at least on Mac/m68k the palette is inherited from MacOS.
> It would be possible for the Penguin booter to programs the standard console
> palette under MacOS, just before booting the kernel, but as I don't know much
> about Penguin, I have no idea whether that's currently done.
I'm not sure I have the latest version of Penguin, but the version I
have laying around has an option to set the current palette before
loading the kernel. I don't remember if it was on by default.
Brad Boyer
flar@allandria.com
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* Re: md: Change ENOTSUPP to EOPNOTSUPP
From: Ric Wheeler @ 2006-04-29 20:23 UTC (permalink / raw)
To: Molle Bestefich; +Cc: NeilBrown, linux-raid
In-Reply-To: <62b0912f0604290650v6fa0759flace16041c26fa003@mail.gmail.com>
Molle Bestefich wrote:
> Ric Wheeler wrote:
>
>> You are absolutely right - if you do not have a validated, working
>> barrier for your low level devices (or a high end, battery backed array
>> or JBOD), you should disable the write cache on your RAIDed partitions
>> and on your normal file systems ;-)
>>
>> There is working support for SCSI (or libata S-ATA) barrier operations
>> in mainline, but they conflict with queue enable targets which ends up
>> leaving queuing on and disabling the barriers.
>
>
> Thank you very much for the information!
>
> How can I check that I have a validated, working barrier with my
> particular kernel version etc.?
> (Do I just assume that since it's not SCSI, it doesn't work?)
The support is in for all drive types now, but you do have to check.
You should look in /var/log/messages and see that you have something
like this:
Mar 29 16:07:19 localhost kernel: ReiserFS: sda14: warning: reiserfs:
option "skip_busy" is set
Mar 29 16:07:19 localhost kernel: ReiserFS: sda14: warning: allocator
options = [00000020]
Mar 29 16:07:19 localhost kernel:
Mar 29 16:07:19 localhost kernel: ReiserFS: sda14: found reiserfs
format "3.6" with standard journal
Mar 29 16:07:19 localhost kernel: ReiserFS: sdc14: Using r5 hash to
sort names
Mar 29 16:07:19 localhost kernel: ReiserFS: sda14: using ordered data mode
Mar 29 16:07:20 localhost kernel: reiserfs: using flush barriers
You can also do a sanity check on the number of synchronous IO's/second
and make sure that it seems sane for your class of drive. For example,
I use a simple test which creates files, fills them and then fsync's
each file before close.
With the barrier on and write cache active, I can write about 30 (10k)
files/sec to a new file system. I get the same number with no barrier
and write cache off which is what you would expect.
If you manually mount with barriers off and the write cache on however,
your numbers will jump up to about 852 (10k) files/sec. This is the one
to look out for ;-)
>
> I find it, hmm... stupefying? horrendous? completely brain dead? I
> don't know.. that noone warns users about this. I bet there's a
> million people out there, happily using MD (probably installed and
> initialized it with Fedora Core / anaconda) and thinking their data is
> safe, while in fact it is anything but. Damn, this is not a good
> situation..
The wide spread use of the write barrier is pretty new stuff. In
fairness, the accepted wisdom is (and has been for a long time) to
always run with write cache off if you care about your data integrity
(again, regardless of MD or native file system). Think of the write
barrier support as a great performance boost (I can see almost a 50% win
in some cases), but getting it well understood and routinely tested is
still a challenge.
>
> (Any suggestions for a good place to fix this? Better really really
> really late than never...)
Good test suites and lots of user testing...
ric
^ permalink raw reply
* young
From: Connor Tran @ 2006-04-29 20:16 UTC (permalink / raw)
To: nfs
[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #1.2: Type: text/html, Size: 417 bytes --]
[-- Attachment #2: continued.gif --]
[-- Type: image/gif, Size: 38030 bytes --]
^ permalink raw reply
* Re: netboot related projects
From: Marco Gerards @ 2006-04-29 20:15 UTC (permalink / raw)
To: The development of GRUB 2
In-Reply-To: <445388B5.1010601@imperial.ac.uk>
vincent guffens <v.guffens@imperial.ac.uk> writes:
Hi Vincent,
> I just wanted to let you know that I contacted the maintainer of
> Etherboot to inform him of my current attempt to port the etherboot
> drivers to grub2.
Is he willing to cooperate with us so it will be easier to share code?
I think I once sent him an email about it... But I am not sure
anymore. :-)
--
Marco
^ permalink raw reply
* [U-Boot-Users] u-boot scripts can contain "if" and "loops"?
From: Antonio Di Bacco @ 2006-04-29 20:09 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20060429200352.1FC77353DAC@atlas.denx.de>
Thank you, this u-boot is wonderful!
On Saturday 29 April 2006 22:03, Wolfgang Denk wrote:
> In message <200604292157.15286.antonio.dibacco@aruba.it> you wrote:
> > Anyone knows how to write an environment variable with a script inside
> > containing if or loops?
>
> setenv foo 'if imi 40040000 ; then bootm 40040000 ; else dhcp ; bootm ; fi'
>
> Of course this requires that you have the hush shell enabled in your
> board configuration; see also
> http://www.denx.de/wiki/view/DULG/CommandLineParsing
>
> Best regards,
>
> Wolfgang Denk
^ permalink raw reply
* [PATCH] Proper reference counting for AX.25 routes.
From: Ralf Baechle DL5RB @ 2006-04-29 20:05 UTC (permalink / raw)
To: linux-hams
Below patch fixes the reference counting for AX.25 routes. It also gets
rid of the timer madness which currently is being used for routing table
entries that are still busy at the time of their removal from the routing
table.
Please test this,
73 de DL5RB op Ralf
--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21
Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
include/net/ax25.h | 24 +++++++++++++++---------
net/ax25/ax25_ip.c | 23 +++++++++++++++--------
net/ax25/ax25_route.c | 49 ++++++++-----------------------------------------
3 files changed, 38 insertions(+), 58 deletions(-)
Index: linux-net.git/include/net/ax25.h
===================================================================
--- linux-net.git.orig/include/net/ax25.h 2006-04-29 15:27:57.000000000 +0100
+++ linux-net.git/include/net/ax25.h 2006-04-29 15:28:15.000000000 +0100
@@ -183,14 +183,26 @@ typedef struct {
typedef struct ax25_route {
struct ax25_route *next;
- atomic_t ref;
+ atomic_t refcount;
ax25_address callsign;
struct net_device *dev;
ax25_digi *digipeat;
char ip_mode;
- struct timer_list timer;
} ax25_route;
+static inline void ax25_hold_route(ax25_route *ax25_rt)
+{
+ atomic_inc(&ax25_rt->refcount);
+}
+
+extern void __ax25_put_route(ax25_route *ax25_rt);
+
+static inline void ax25_put_route(ax25_route *ax25_rt)
+{
+ if (atomic_dec_and_test(&ax25_rt->refcount))
+ __ax25_put_route(ax25_rt);
+}
+
typedef struct {
char slave; /* slave_mode? */
struct timer_list slave_timer; /* timeout timer */
@@ -349,17 +361,11 @@ extern int ax25_check_iframes_acked(ax2
extern void ax25_rt_device_down(struct net_device *);
extern int ax25_rt_ioctl(unsigned int, void __user *);
extern struct file_operations ax25_route_fops;
+extern ax25_route *ax25_get_route(ax25_address *addr, struct net_device *dev);
extern int ax25_rt_autobind(ax25_cb *, ax25_address *);
-extern ax25_route *ax25_rt_find_route(ax25_route *, ax25_address *,
- struct net_device *);
extern struct sk_buff *ax25_rt_build_path(struct sk_buff *, ax25_address *, ax25_address *, ax25_digi *);
extern void ax25_rt_free(void);
-static inline void ax25_put_route(ax25_route *ax25_rt)
-{
- atomic_dec(&ax25_rt->ref);
-}
-
/* ax25_std_in.c */
extern int ax25_std_frame_in(ax25_cb *, struct sk_buff *, int);
Index: linux-net.git/net/ax25/ax25_ip.c
===================================================================
--- linux-net.git.orig/net/ax25/ax25_ip.c 2006-04-29 14:40:33.000000000 +0100
+++ linux-net.git/net/ax25/ax25_ip.c 2006-04-29 15:28:15.000000000 +0100
@@ -104,11 +104,13 @@ int ax25_rebuild_header(struct sk_buff *
{
struct sk_buff *ourskb;
unsigned char *bp = skb->data;
- struct net_device *dev;
+ ax25_route *route;
+ struct net_device *dev = NULL;
ax25_address *src, *dst;
+ ax25_digi *digipeat = NULL;
ax25_dev *ax25_dev;
- ax25_route _route, *route = &_route;
ax25_cb *ax25;
+ char ip_mode = ' ';
dst = (ax25_address *)(bp + 1);
src = (ax25_address *)(bp + 8);
@@ -116,8 +118,12 @@ int ax25_rebuild_header(struct sk_buff *
if (arp_find(bp + 1, skb))
return 1;
- route = ax25_rt_find_route(route, dst, NULL);
- dev = route->dev;
+ route = ax25_get_route(dst, NULL);
+ if (route) {
+ digipeat = route->digipeat;
+ dev = route->dev;
+ ip_mode = route->ip_mode;
+ };
if (dev == NULL)
dev = skb->dev;
@@ -127,7 +133,7 @@ int ax25_rebuild_header(struct sk_buff *
}
if (bp[16] == AX25_P_IP) {
- if (route->ip_mode == 'V' || (route->ip_mode == ' ' && ax25_dev->values[AX25_VALUES_IPDEFMODE])) {
+ if (ip_mode == 'V' || (ip_mode == ' ' && ax25_dev->values[AX25_VALUES_IPDEFMODE])) {
/*
* We copy the buffer and release the original thereby
* keeping it straight
@@ -173,7 +179,7 @@ int ax25_rebuild_header(struct sk_buff *
ourskb,
ax25_dev->values[AX25_VALUES_PACLEN],
&src_c,
- &dst_c, route->digipeat, dev);
+ &dst_c, digipeat, dev);
if (ax25) {
ax25_cb_put(ax25);
}
@@ -191,7 +197,7 @@ int ax25_rebuild_header(struct sk_buff *
skb_pull(skb, AX25_KISS_HEADER_LEN);
- if (route->digipeat != NULL) {
+ if (digipeat != NULL) {
if ((ourskb = ax25_rt_build_path(skb, src, dst, route->digipeat)) == NULL) {
kfree_skb(skb);
goto put;
@@ -203,7 +209,8 @@ int ax25_rebuild_header(struct sk_buff *
ax25_queue_xmit(skb, dev);
put:
- ax25_put_route(route);
+ if (route)
+ ax25_put_route(route);
return 1;
}
Index: linux-net.git/net/ax25/ax25_route.c
===================================================================
--- linux-net.git.orig/net/ax25/ax25_route.c 2006-04-29 15:23:13.000000000 +0100
+++ linux-net.git/net/ax25/ax25_route.c 2006-04-29 15:28:15.000000000 +0100
@@ -41,8 +41,6 @@
static ax25_route *ax25_route_list;
static DEFINE_RWLOCK(ax25_route_lock);
-static ax25_route *ax25_get_route(ax25_address *, struct net_device *);
-
void ax25_rt_device_down(struct net_device *dev)
{
ax25_route *s, *t, *ax25_rt;
@@ -115,7 +113,7 @@ static int ax25_rt_add(struct ax25_route
return -ENOMEM;
}
- atomic_set(&ax25_rt->ref, 0);
+ atomic_set(&ax25_rt->refcount, 1);
ax25_rt->callsign = route->dest_addr;
ax25_rt->dev = ax25_dev->dev;
ax25_rt->digipeat = NULL;
@@ -140,23 +138,10 @@ static int ax25_rt_add(struct ax25_route
return 0;
}
-static void ax25_rt_destroy(ax25_route *ax25_rt)
+void __ax25_put_route(ax25_route *ax25_rt)
{
- if (atomic_read(&ax25_rt->ref) == 0) {
- kfree(ax25_rt->digipeat);
- kfree(ax25_rt);
- return;
- }
-
- /*
- * Uh... Route is still in use; we can't yet destroy it. Retry later.
- */
- init_timer(&ax25_rt->timer);
- ax25_rt->timer.data = (unsigned long) ax25_rt;
- ax25_rt->timer.function = (void *) ax25_rt_destroy;
- ax25_rt->timer.expires = jiffies + 5 * HZ;
-
- add_timer(&ax25_rt->timer);
+ kfree(ax25_rt->digipeat);
+ kfree(ax25_rt);
}
static int ax25_rt_del(struct ax25_routes_struct *route)
@@ -177,12 +162,12 @@ static int ax25_rt_del(struct ax25_route
ax25cmp(&route->dest_addr, &s->callsign) == 0) {
if (ax25_route_list == s) {
ax25_route_list = s->next;
- ax25_rt_destroy(s);
+ ax25_put_route(s);
} else {
for (t = ax25_route_list; t != NULL; t = t->next) {
if (t->next == s) {
t->next = s->next;
- ax25_rt_destroy(s);
+ ax25_put_route(s);
break;
}
}
@@ -362,7 +347,7 @@ struct file_operations ax25_route_fops =
*
* Only routes with a reference count of zero can be destroyed.
*/
-static ax25_route *ax25_get_route(ax25_address *addr, struct net_device *dev)
+ax25_route *ax25_get_route(ax25_address *addr, struct net_device *dev)
{
ax25_route *ax25_spe_rt = NULL;
ax25_route *ax25_def_rt = NULL;
@@ -392,7 +377,7 @@ static ax25_route *ax25_get_route(ax25_a
ax25_rt = ax25_spe_rt;
if (ax25_rt != NULL)
- atomic_inc(&ax25_rt->ref);
+ ax25_hold_route(ax25_rt);
read_unlock(&ax25_route_lock);
@@ -467,24 +452,6 @@ put:
return 0;
}
-ax25_route *ax25_rt_find_route(ax25_route * route, ax25_address *addr,
- struct net_device *dev)
-{
- ax25_route *ax25_rt;
-
- if ((ax25_rt = ax25_get_route(addr, dev)))
- return ax25_rt;
-
- route->next = NULL;
- atomic_set(&route->ref, 1);
- route->callsign = *addr;
- route->dev = dev;
- route->digipeat = NULL;
- route->ip_mode = ' ';
-
- return route;
-}
-
struct sk_buff *ax25_rt_build_path(struct sk_buff *skb, ax25_address *src,
ax25_address *dest, ax25_digi *digi)
{
^ permalink raw reply
* [U-Boot-Users] u-boot scripts can contain "if" and "loops"?
From: Wolfgang Denk @ 2006-04-29 20:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <200604292157.15286.antonio.dibacco@aruba.it>
In message <200604292157.15286.antonio.dibacco@aruba.it> you wrote:
> Anyone knows how to write an environment variable with a script inside
> containing if or loops?
setenv foo 'if imi 40040000 ; then bootm 40040000 ; else dhcp ; bootm ; fi'
Of course this requires that you have the hush shell enabled in your
board configuration; see also
http://www.denx.de/wiki/view/DULG/CommandLineParsing
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
We have phasers, I vote we blast 'em!
-- Bailey, "The Corbomite Maneuver", stardate 1514.2
^ permalink raw reply
* Variable context
From: Marco Gerards @ 2006-04-29 20:05 UTC (permalink / raw)
To: The development of GRUB
Hi,
Here is a patch for making variables dependant on the context. Now
when the user uses configfile, another context is created. Like in
bash you can make variables global by using `export'.
--
Marco
2006-04-29 Marco Gerards <marco@gnu.org>
* commands/configfile.c (grub_cmd_configfile): Execute the
configfile within its own context.
* include/grub/env.h (grub_env_context_open): New prototype.
(grub_env_context_close): Likewise.
(grub_env_init): Likewise.
* kern/env.c (grub_env): Removed.
(grub_env_sorted): Likewise.
(grub_env_context): New variable.
(grub_env_var_context): Likewise.
(grub_env_find): Search both the active context and the global
context.
(grub_env_context_open): New function.
(grub_env_context_close): Likewise.
(grub_env_init): Likewise.
(grub_env_insert): Likewise.
(grub_env_remove): Likewise.
(grub_env_export): Likewise.
(grub_env_set): Changed to use helper functions to avoid code
duplication.
(grub_env_iterate): Rewritten so both the current context and the
global context are being used.
* kern/i386/pc/init.c (grub_machine_init): Call `grub_env_init'.
* kern/powerpc/ieee1275/init.c (grub_machine_init): Likewise.
* kern/sparc64/ieee1275/init.c (grub_machine_init): Likewise.
* util/grub-emu.c (grub_machine_init): Likewise.
* kern/efi/init.c (grub_efi_init): Likewise.
* normal/command.c (export_command): New function.
(grub_command_init): Register the `export' function.
Index: commands/configfile.c
===================================================================
RCS file: /sources/grub/grub2/commands/configfile.c,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 configfile.c
--- commands/configfile.c 13 Nov 2005 15:47:08 -0000 1.3
+++ commands/configfile.c 29 Apr 2006 20:02:17 -0000
@@ -1,7 +1,7 @@
/* configfile.c - command to manually load config file */
/*
* GRUB -- GRand Unified Bootloader
- * Copyright (C) 2005 Free Software Foundation, Inc.
+ * Copyright (C) 2005,2006 Free Software Foundation, Inc.
*
* GRUB is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -33,7 +33,9 @@ grub_cmd_configfile (struct grub_arg_lis
return grub_error (GRUB_ERR_BAD_ARGUMENT, "file name required");
grub_cls ();
+ grub_env_context_open ();
grub_normal_execute (args[0], 1);
+ grub_env_context_close ();
return 0;
}
Index: include/grub/env.h
===================================================================
RCS file: /sources/grub/grub2/include/grub/env.h,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 env.h
--- include/grub/env.h 20 Jul 2005 20:30:45 -0000 1.3
+++ include/grub/env.h 29 Apr 2006 20:02:17 -0000
@@ -1,6 +1,6 @@
/*
* GRUB -- GRand Unified Bootloader
- * Copyright (C) 2003,2005 Free Software Foundation, Inc.
+ * Copyright (C) 2003,2005,2006 Free Software Foundation, Inc.
*
* GRUB is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -50,5 +50,8 @@ void EXPORT_FUNC(grub_env_iterate) (int
grub_err_t EXPORT_FUNC(grub_register_variable_hook) (const char *var,
grub_env_read_hook_t read_hook,
grub_env_write_hook_t write_hook);
+grub_err_t EXPORT_FUNC(grub_env_context_open) (void);
+grub_err_t EXPORT_FUNC(grub_env_context_close) (void);
+grub_err_t EXPORT_FUNC(grub_env_init) (void);
#endif /* ! GRUB_ENV_HEADER */
Index: kern/env.c
===================================================================
RCS file: /sources/grub/grub2/kern/env.c,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 env.c
--- kern/env.c 25 Dec 2005 17:21:52 -0000 1.5
+++ kern/env.c 29 Apr 2006 20:02:17 -0000
@@ -1,7 +1,7 @@
/* env.c - Environment variables */
/*
* GRUB -- GRand Unified Bootloader
- * Copyright (C) 2003,2005 Free Software Foundation, Inc.
+ * Copyright (C) 2003,2005,2006 Free Software Foundation, Inc.
*
* GRUB is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -26,10 +26,21 @@
#define HASHSZ 13
/* A hashtable for quick lookup of variables. */
-static struct grub_env_var *grub_env[HASHSZ];
+struct grub_env_context
+{
+ struct grub_env_var *vars[HASHSZ];
+
+ struct grub_env_var *sorted;
+
+ /* One level deeper on the stack. */
+ struct grub_env_context *next;
+};
+
+/* The global context for environment variables. */
+static struct grub_env_context *grub_env_context;
-/* The variables in a sorted list. */
-static struct grub_env_var *grub_env_sorted;
+/* The nested contexts for regular variables. */
+static struct grub_env_context *grub_env_var_context;
/* Return the hash representation of the string S. */
static unsigned int grub_env_hashval (const char *s)
@@ -49,20 +60,155 @@ grub_env_find (const char *name)
struct grub_env_var *var;
int idx = grub_env_hashval (name);
- for (var = grub_env[idx]; var; var = var->next)
+ /* Look for the variable in the current context. */
+ for (var = grub_env_var_context->vars[idx]; var; var = var->next)
if (! grub_strcmp (var->name, name))
return var;
+
+ /* Look for the variable in the environment context. */
+ for (var = grub_env_context->vars[idx]; var; var = var->next)
+ if (! grub_strcmp (var->name, name))
+ return var;
+
return 0;
}
grub_err_t
-grub_env_set (const char *var, const char *val)
+grub_env_context_open (void)
{
- int idx = grub_env_hashval (var);
+ struct grub_env_context *context;
+ int i;
+
+ context = grub_malloc (sizeof (*context));
+ if (! context)
+ return grub_errno;
+
+ for (i = 0; i < HASHSZ; i++)
+ context->vars[i] = 0;
+ context->next = grub_env_var_context;
+ context->sorted = 0;
+
+ grub_env_var_context = context;
+
+ return GRUB_ERR_NONE;
+}
+
+grub_err_t
+grub_env_context_close (void)
+{
+ struct grub_env_context *context;
struct grub_env_var *env;
+ struct grub_env_var *prev = 0;
+
+ context = grub_env_var_context->next;
+
+ /* Free the variables associated with this context. */
+ for (env = grub_env_var_context->sorted; env; env = env->sort_next)
+ {
+ /* XXX: What if a hook is associated with this variable? */
+ grub_free (prev);
+ prev = env;
+ }
+ grub_free (prev);
+
+ /* Restore the previous context. */
+ grub_free (grub_env_var_context);
+ grub_env_var_context = context;
+
+ return GRUB_ERR_NONE;
+}
+
+grub_err_t
+grub_env_init (void)
+{
+ grub_err_t err;
+
+ /* Create the hashtable for the environment variables. */
+ err = grub_env_context_open ();
+ if (err)
+ return err;
+
+ /* Use this one for environment variables only. */
+ grub_env_context = grub_env_var_context;
+
+ return GRUB_ERR_NONE;
+}
+
+static void
+grub_env_insert (struct grub_env_context *context,
+ struct grub_env_var *env)
+{
+ struct grub_env_var **grub_env = context->vars;
struct grub_env_var *sort;
struct grub_env_var **sortp;
-
+ int idx = grub_env_hashval (env->name);
+
+ /* Insert it in the hashtable. */
+ env->prevp = &grub_env[idx];
+ env->next = grub_env[idx];
+ if (grub_env[idx])
+ grub_env[idx]->prevp = &env->next;
+ grub_env[idx] = env;
+
+ /* Insert it in the sorted list. */
+ sortp = &context->sorted;
+ sort = context->sorted;
+ while (sort)
+ {
+ if (grub_strcmp (sort->name, env->name) > 0)
+ break;
+
+ sortp = &sort->sort_next;
+ sort = sort->sort_next;
+ }
+ env->sort_prevp = sortp;
+ env->sort_next = sort;
+ if (sort)
+ sort->sort_prevp = &env->sort_next;
+ *sortp = env;
+}
+
+
+static void
+grub_env_remove (struct grub_env_var *env)
+{
+ /* Remove the entry from the variable table. */
+ *env->prevp = env->next;
+ if (env->next)
+ env->next->prevp = env->prevp;
+
+ /* And from the sorted list. */
+ *env->sort_prevp = env->sort_next;
+ if (env->sort_next)
+ env->sort_next->sort_prevp = env->sort_prevp;
+}
+
+grub_err_t
+grub_env_export (const char *var)
+{
+ struct grub_env_var *env;
+ int idx = grub_env_hashval (var);
+
+ /* Look for the variable in the current context only. */
+ for (env = grub_env_var_context->vars[idx]; env; env = env->next)
+ if (! grub_strcmp (env->name, var))
+ {
+ /* Remove the variable from the old context and reinsert it
+ into the environment. */
+ grub_env_remove (env);
+ grub_env_insert (grub_env_context, env);
+
+ return GRUB_ERR_NONE;
+ }
+
+ return GRUB_ERR_NONE;
+}
+
+grub_err_t
+grub_env_set (const char *var, const char *val)
+{
+ struct grub_env_var *env;
+
/* If the variable does already exist, just update the variable. */
env = grub_env_find (var);
if (env)
@@ -98,30 +244,8 @@ grub_env_set (const char *var, const cha
env->value = grub_strdup (val);
if (! env->value)
goto fail;
-
- /* Insert it in the hashtable. */
- env->prevp = &grub_env[idx];
- env->next = grub_env[idx];
- if (grub_env[idx])
- grub_env[idx]->prevp = &env->next;
- grub_env[idx] = env;
-
- /* Insert it in the sorted list. */
- sortp = &grub_env_sorted;
- sort = grub_env_sorted;
- while (sort)
- {
- if (grub_strcmp (sort->name, var) > 0)
- break;
-
- sortp = &sort->sort_next;
- sort = sort->sort_next;
- }
- env->sort_prevp = sortp;
- env->sort_next = sort;
- if (sort)
- sort->sort_prevp = &env->sort_next;
- *sortp = env;
+
+ grub_env_insert (grub_env_var_context, env);
return 0;
@@ -160,13 +284,7 @@ grub_env_unset (const char *name)
if (env->read_hook || env->write_hook)
return;
- *env->prevp = env->next;
- if (env->next)
- env->next->prevp = env->prevp;
-
- *env->sort_prevp = env->sort_next;
- if (env->sort_next)
- env->sort_next->sort_prevp = env->sort_prevp;
+ grub_env_remove (env);
grub_free (env->name);
grub_free (env->value);
@@ -177,11 +295,32 @@ grub_env_unset (const char *name)
void
grub_env_iterate (int (* func) (struct grub_env_var *var))
{
- struct grub_env_var *env;
+ struct grub_env_var *env = grub_env_context->sorted;
+ struct grub_env_var *var = grub_env_var_context->sorted;
+
+ /* Initially these are the same. */
+ if (env == var)
+ var = 0;
- for (env = grub_env_sorted; env; env = env->sort_next)
- if (func (env))
- return;
+ while (env || var)
+ {
+ struct grub_env_var **cur;
+
+ /* Select the first name to be printed from the head of two
+ sorted lists. */
+ if (! env)
+ cur = &var;
+ else if (! var)
+ cur = &env;
+ else if (grub_strcmp (env->name, var->name) > 0)
+ cur = &var;
+ else
+ cur = &env;
+
+ if (func (*cur))
+ return;
+ *cur = (*cur)->sort_next;
+ }
}
grub_err_t
Index: kern/efi/init.c
===================================================================
RCS file: /sources/grub/grub2/kern/efi/init.c,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 init.c
--- kern/efi/init.c 25 Apr 2006 20:08:31 -0000 1.3
+++ kern/efi/init.c 29 Apr 2006 20:02:17 -0000
@@ -38,6 +38,8 @@ grub_efi_init (void)
/* Initialize the memory management system. */
grub_efi_mm_init ();
+ grub_env_init ();
+
grub_efidisk_init ();
}
Index: kern/i386/pc/init.c
===================================================================
RCS file: /sources/grub/grub2/kern/i386/pc/init.c,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 init.c
--- kern/i386/pc/init.c 25 Apr 2006 20:08:31 -0000 1.12
+++ kern/i386/pc/init.c 29 Apr 2006 20:02:17 -0000
@@ -1,6 +1,6 @@
/*
* GRUB -- GRand Unified Bootloader
- * Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
+ * Copyright (C) 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -226,6 +226,8 @@ grub_machine_init (void)
/* The memory system was initialized, thus register built-in devices. */
grub_biosdisk_init ();
+
+ grub_env_init ();
}
void
Index: kern/powerpc/ieee1275/init.c
===================================================================
RCS file: /sources/grub/grub2/kern/powerpc/ieee1275/init.c,v
retrieving revision 1.25
diff -u -p -u -p -r1.25 init.c
--- kern/powerpc/ieee1275/init.c 26 Apr 2006 02:20:12 -0000 1.25
+++ kern/powerpc/ieee1275/init.c 29 Apr 2006 20:02:17 -0000
@@ -1,7 +1,7 @@
/* init.c -- Initialize GRUB on the newworld mac (PPC). */
/*
* GRUB -- GRand Unified Bootloader
- * Copyright (C) 2003, 2004, 2005 Free Software Foundation, Inc.
+ * Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -134,6 +134,8 @@ grub_machine_init (void)
}
grub_mm_init_region ((void *) grub_heap_start, grub_heap_len);
+ grub_env_init ();
+
grub_ofdisk_init ();
/* Process commandline. */
Index: kern/sparc64/ieee1275/init.c
===================================================================
RCS file: /sources/grub/grub2/kern/sparc64/ieee1275/init.c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 init.c
--- kern/sparc64/ieee1275/init.c 25 Apr 2006 20:08:31 -0000 1.2
+++ kern/sparc64/ieee1275/init.c 29 Apr 2006 20:02:17 -0000
@@ -1,7 +1,7 @@
/* init.c -- Initialize GRUB on the Ultra Sprac (sparc64). */
/*
* GRUB -- GRand Unified Bootloader
- * Copyright (C) 2003, 2004, 2005 Free Software Foundation, Inc.
+ * Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -156,6 +156,8 @@ grub_machine_init (void)
grub_heap_len);
grub_mm_init_region ((void *) grub_heap_start, grub_heap_len);
+ grub_env_init ();
+
grub_ofdisk_init ();
/* Process commandline. */
Index: normal/command.c
===================================================================
RCS file: /sources/grub/grub2/normal/command.c,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 command.c
--- normal/command.c 16 Apr 2006 18:02:42 -0000 1.16
+++ normal/command.c 29 Apr 2006 20:02:17 -0000
@@ -1,6 +1,6 @@
/*
* GRUB -- GRand Unified Bootloader
- * Copyright (C) 2003,2005 Free Software Foundation, Inc.
+ * Copyright (C) 2003,2005,2006 Free Software Foundation, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -284,6 +284,18 @@ unset_command (struct grub_arg_list *sta
}
static grub_err_t
+export_command (struct grub_arg_list *state __attribute__ ((unused)),
+ int argc, char **args)
+{
+ if (argc < 1)
+ return grub_error (GRUB_ERR_BAD_ARGUMENT,
+ "no environment variable specified");
+
+ grub_env_export (args[0]);
+ return 0;
+}
+
+static grub_err_t
insmod_command (struct grub_arg_list *state __attribute__ ((unused)),
int argc, char **args)
{
@@ -367,6 +379,9 @@ grub_command_init (void)
grub_register_command ("unset", unset_command, GRUB_COMMAND_FLAG_BOTH,
"unset ENVVAR", "Remove an environment variable.", 0);
+ grub_register_command ("export", export_command, GRUB_COMMAND_FLAG_BOTH,
+ "export ENVVAR", "Export a variable.", 0);
+
grub_register_command ("insmod", insmod_command, GRUB_COMMAND_FLAG_BOTH,
"insmod MODULE",
"Insert a module. The argument can be a file or a module name.",
Index: util/grub-emu.c
===================================================================
RCS file: /sources/grub/grub2/util/grub-emu.c,v
retrieving revision 1.29
diff -u -p -u -p -r1.29 grub-emu.c
--- util/grub-emu.c 26 Apr 2006 21:58:36 -0000 1.29
+++ util/grub-emu.c 29 Apr 2006 20:02:17 -0000
@@ -83,6 +83,7 @@ void
grub_machine_init (void)
{
signal (SIGINT, SIG_IGN);
+ grub_env_init ();
grub_console_init ();
}
^ permalink raw reply
* [U-Boot-Users] u-boot scripts can contain "if" and "loops"?
From: Antonio Di Bacco @ 2006-04-29 19:57 UTC (permalink / raw)
To: u-boot
Anyone knows how to write an environment variable with a script inside
containing if or loops?
Bye,
Antonio.
^ permalink raw reply
* PROBLEM: ramfs reports 0 free
From: Senior Goat @ 2006-04-29 19:52 UTC (permalink / raw)
To: linux-kernel
[1.] One line summary of the problem:
ramfs erroneously reports 0 bytes free, which confuses some programs.
[2.] Full description of the problem/report:
The system call on a mounted ramfs, as indicated by df, reports 0 bytes
total, used, and free. If ramfs is expected to perform like a filesystem,
it should not do this.
[3.] Keywords (i.e., modules, networking, kernel):
ramfs, free space, used space, total space, zero, 0, module, kernel,
filesystem, ram, statfs, ustat
[4.] Kernel version (from /proc/version):
Linux version 2.6.16-1-686 (Debian 2.6.16-9) (waldi@debian.org) (gcc
version 4.0.3 (Debian 4.0.3-1)) #2 Thu Apr 20 20:35:02 UTC 2006
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
no oops.
[6.] A small shell script or example program which triggers the
problem (if possible)
(modprobe ramfs)
mkdir ramfs
mount none ramfs -t ramfs
df ramfs/
[7.] Environment
not relevant
[7.1.] Software (add the output of the ver_linux script here)
Linux spider 2.6.16-1-486 #2 Tue Apr 25 20:33:31 UTC 2006 i686 GNU/Linux
Gnu C 4.0.4
Gnu make 3.81
binutils 2.16.91
util-linux 2.12r
mount 2.12r
module-init-tools 3.2.2
e2fsprogs 1.39-WIP
reiserfsprogs line
reiser4progs line
nfs-utils 1.0.7
Linux C Library 2.3.6
Dynamic linker (ldd) 2.3.6
Procps 3.2.6
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.94
Modules Loaded ipv6 pcspkr snd_via82xx gameport snd_ac97_codec
snd_ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi
snd_seq_device snd soundcore i2c_viapro vt8231 i2c_isa i2c_core parport_pc
parport shpchp pci_hotplug via_agp agpgart uhci_hcd usbcore e100 via_rhine
mii via_ircc irda crc_ccitt dm_mod psmouse ide_generic ide_cd cdrom rtc ext3
jbd ide_disk generic via82cxxx ide_core evdev mousedev
[7.2.] Processor information (from /proc/cpuinfo):
not relevant, but including because it only draws 4W
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 7
model name : VIA Samuel 2
stepping : 3
cpu MHz : 533.507
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow
bogomips : 1067.94
[7.3.] Module information (from /proc/modules):
not relevant
using compiled in ramfs, not as a module
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
not relevant
[7.5.] PCI information ('lspci -vvv' as root)
not relevant
[7.6.] SCSI information (from /proc/scsi/scsi)
none / not relevant
[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
[X.] Other notes, patches, fixes, workarounds:
I read that Linus himself wrote this module. For some reason he decided
to report 0, but I can't figure why. Perhaps the overhead for finding
information was too great.
Couldn't you add up the amount of filesystem cache with the free memory
and get a crude, but quick estimate of the amount of free space available
for any given ramfs.
I'm not sure how to handle the total space, since you probably don't want
that fluctuating too much, except that you might just report the total
amount of ram(which won't fluctuate), and then report the used ram. This is
all information that /free/ reports from system calls with little delay.
The only other place I can think that ramfs might get memory is when the
kernel swaps out other processes, but you can't count on that.
To sum it up, the best way to get a semi-valid report would be:
total: total ram
used: used ram (which takes into account memory used in the ramfs,
coincidentally)
free: total - used (which ignores disk cache, since that should be freed
when needed)
The other option would be to make all the little programs (like Debian's
package manager) check if the filesystem it wants to write to is a ramfs
before reporting an error, but this is a blatant hack.
^ permalink raw reply
* Re: [PATCH] Calculate correct instruction length for data-fault VM exits on VT-x systems
From: Keir Fraser @ 2006-04-29 19:46 UTC (permalink / raw)
To: leendert; +Cc: Mats, xen-devel, Khoa Huynh
In-Reply-To: <1146361026.2528.48.camel@localhost.localdomain>
On 30 Apr 2006, at 02:37, Leendert van Doorn wrote:
>> How does this work now? Do we really have two copies of each device
>> model? I doubt that's implemented safely.
>
> Right now the realmode code runs inside the VMX partition where it is
> partially emulated by vmxassist. So all accesses to the emulated
> devices
> go through the hypervisor first before they (potentially) end up in
> qemu-dm. When a transition is made to 32/64-bit code all the
> initialized
> device state is still there.
Ah yes, I forgot that the mmio decoder stuff in Xen handles real mode.
So that means that currently each device model is either implemented in
Xen or in qemu-dm, but not both (now that the heinous split PIT device
model is gone). That's a nice state of affairs.
> The problem of keeping the the hypervisor state and the qemu-dm state
> in
> sync is introduced when we alternate between emulation and real
> execution. This becomes more interesting when we consider MP guests
> where one CPU is running inside the emulator and another on the real
> hardware.
It'd obviously be better avoided altogether, unless we have to perform
horrible contortions to do so, or if doing so would hurt performance of
operations that we care about.
Don't get me wrong by the way: I do think that leveraging qemu's full
emulator, at least to get us out of the stickiest situations, is a very
good idea. I'm only concerned about some of the finer details.
-- Keir
^ permalink raw reply
* Re: [PATCH 2/3] rt2x00 drivers: rt61pci
From: Ivo van Doorn @ 2006-04-29 19:35 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, rt2x00-devel
In-Reply-To: <20060429161002.GA3345@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]
On Saturday 29 April 2006 18:10, Francois Romieu wrote:
> Ivo van Doorn <ivdoorn@gmail.com> :
> [...]
> > Not sure about that either. I usually choose the type of the counter
> > depending on the max size of that counter.
>
> It is not arch-neutral. powerpc favors unsigned int over int but I am
> too lazy to check if the size matters.
Ok, I'll make sure the counters will made of the unsigned int type.
> [...]
> > Perhaps, but I prefer the usage of the name "counter".
> > I am not sure if there is a coding style about this? If so I could
> > rename "counter" to "i".
>
> Chapter 4 of Documentation/CodingStyle goes in this direction.
> The document is not meant to be a taken too literally though.
>
> The repetitive use of 'counter' + foo[counter].blah tends to be a
> bit bloaty.
>
> [...]
> > I'll create a bugreport in the rt2x00 project bugzilla
> > with some of the coding style change requests.
>
> I will not complain if you open a bugreport to provide a git repo
> as well.
>
> /me hides...
The git repository has indeed been discussed between the
rt2x00 developers before. And at the moment we see no major
benefit from using git. We need to have something like CVS
for regular users to use rt2x00 and we don't want them to
use git only to use the drivers.
In the CVS tree we have multiple backwards compatibility
fixes for both rt2x00 as the dscape stack to make it work
on kernel 2.6.13 and above. So making a git repository
would mean a lot duplicate work, since we have to keep
2 trees up to date, as well as making sure the wireless-dev
tree contains an up to date version.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: Junio C Hamano @ 2006-04-29 19:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e309vq$m2r$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> IF (and that is big if) git commit header will be extended to have some
> extra "link" (enforcing connectivity) headers, like proposed "bind" for
> subprojects, "prev" for pu-like union branches, "merge-base" for merges,
> there would be repeated work on enforcing connectivity. Hence generic
> "link" header (formerly "related") proposal.
The "link <sha1> <type> <meta>" header extension was done
primarily for that reason this way. I carried it in my "pu"
branch for a few days but Linus convinced me privately that it
was a bad idea, so it is not merged in "pu" anymore. Just to
make it easy for people to view what we are discussing, I pushed
the branch head to jc/bind-2 topic branch, but the code will
_not_ be merged.
The code in commit.c to recognize and link the releated objects
pointed by the "link" header to the commit looked like below
(see 11bbee26 commit on that branch):
+ optr = &item->links;
+ while (!memcmp(bufptr, "link ", 5)) {
+ struct object *object;
+
+ if (!get_sha1_hex(bufptr + 5, parent) &&
+ bufptr[45] == ' ' &&
+ (object = lookup_unknown_object(parent)) != NULL) {
+ struct object_list *l = xmalloc(sizeof(*l));
+ l->item = object;
+ l->next = *optr;
+ l->name = NULL;
+ *optr = l;
+ optr = &l->next;
+ n_refs++;
+ bufptr += 45;
+ }
+ else
+ return error("bad link in commit %s",
+ sha1_to_hex(item->object.sha1));
+ while (*bufptr++ != '\n')
+ ; /* skip over subdirectory name */
+ }
But if your are going to introduce "merge-base" and similar
headers that have impact to connectivity traversal code, you can
easily change the !memcmp(buptr, "link ", 5) with a sequence of
"memcmp(foo) || memcmp(bar) || ...", and use the "l->name" field
to point at the header itself, so that the user of the resulting
commit object can easily tell what kind of link-like header it
is, and enforce further semantics that are specific to each kind
of such header on it. The revision traversal change that was
done in a later commit (7091fd commit) does not have to change.
The code sharing aspect you brought up is a very important
issue. This is revision traversal, which is really the central
part of git and needs deep thought to touch without breaking, so
we would like to avoid risking breaking it by repeatedly
touching it. But that can be done without making the recorded
header something like "link <sha1> <type> <metainfo>" which is
too generic.
^ permalink raw reply
* Re: Not NATed packets
From: Petr Pisar @ 2006-04-29 19:15 UTC (permalink / raw)
To: netfilter
In-Reply-To: <Pine.LNX.4.64N.0604231700330.6204@tank.eu.org>
lukas@tank.eu.org wrote:
> NAT configuration is simple but some packets are not NATed - on my
> public interface packets with source address of my internal (NATed)
> network appears and i have no clue what is wrong.
>
> tcpdump -i eth0 -n -vvv |grep 10.10.10
> 16:30:39.015880 IP (tos 0x0, ttl 127, id 28594, offset 0, flags [DF],
> proto: TCP (6), length: 40) 10.10.10.104.3689 > 83.29.48.50.6881: F,
> cksum 0x1623 (correct), 3885889894:3885889894(0) ack 3151418643 win 65535
So, I have one workaround. These magic packets are INVALID from point of
state module's view. Therefore this rules
5 200 LOG all -- * ppp0 0.0.0.0/0
0.0.0.0/0 state INVALID LOG flags 2 level 4 prefix `FWD-INVALID'
1 40 REJECT all -- * ppp0 0.0.0.0/0
0.0.0.0/0 state INVALID reject-with icmp-admin-prohibited
where ppp0 is nating device can log and discard this packets.
I'm not sure if any INVALID packet can also be considered as a health
packet. Can you see any false positivities? (I know, that these packets
can occure, when interface with dynamicly assignes address changes its
IP address during established TCP connection, but then we are not able
to repair this state [i.e. close connection on both sides with proper
source IP] either. Therefore we can consider following packets as realy
invalid.)
-- Petr
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.