* Re: [ANNOUNCE] udev 089 release
From: Marco d'Itri @ 2006-04-05 19:36 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20060403171123.GA24860@vrfy.org>
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
On Apr 05, Scott James Remnant <scott@ubuntu.com> wrote:
> In the initramfs, we exercise a little more caution; making sure that we
> only probe PCI IDE or SCSI controllers first before we move on to
> probing for USB buses. The reasoning for this is that we don't want
> someone's fast USB pen drive beating their SATA or SCSI disk to
> getting /dev/sda1
Why would this be a bad?
> This may be unique to Ubuntu where we try to have an initramfs image
> that can do everything, rather than customising it per-install; but then
Debian does too, and it loads everything.
--
ciao,
Marco
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [linux-lvm] Bad disk removal
From: Barnaby Claydon @ 2006-04-05 18:41 UTC (permalink / raw)
To: LVM general discussion and development
Hey all,
So after lots of scans and log review, turns out 1 of the 8 IDE disks in
my LVM is bad. (I know, IDE, yeahyeah...)
I currently have the affected volume group online, and it's mounted in
XFS readonly,norecovery mode. XFS can't attempt repair because one of
the bad sectors is the superblock so xfs_repair bombs.
Unfortunately I don't have 1.2TB of free space available to try and pull
all the data off the VG before rebuilding it and replacing the failed
drive. If I get a replacement for the bad drive and extend the VG, my
question would be:
How fault tolerant is pvmove if it encounters unreadable/bad sectors on
a disk? Will I hose the entire VG if pvmove bombs? Will pvmove skip the
bad sectors after a few attempts and move on? Will pvmove refuse to even
try?
I'm sure someone's had experience with this before. :) (Obviously I
don't have RAID underneath the LVM, otherwise I'm sure this would be
moot... lesson learned.)
Thanks all,
-Barnaby
^ permalink raw reply
* Re: [PATCH] git-commit: document --append
From: Junio C Hamano @ 2006-04-05 19:34 UTC (permalink / raw)
To: Marco Roeland; +Cc: git
In-Reply-To: <20060405191608.GA20572@fiberbit.xs4all.nl>
Thanks for resurrecting this.
I suspect that some formatting tweak is needed; I recall
asciidoc needs some special formatting when multi- paragraph
description is involved in the list.
Of course, munging the patch title with s/append/amend/ would
not hurt ;-).
^ permalink raw reply
* Re: [ANNOUNCE] udev 089 release
From: Scott James Remnant @ 2006-04-05 19:33 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20060403171123.GA24860@vrfy.org>
[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]
On Wed, 2006-04-05 at 20:51 +0200, Kay Sievers wrote:
> On Wed, Apr 05, 2006 at 12:25:34AM +0100, Scott James Remnant wrote:
> > On Mon, 2006-04-03 at 19:11 +0200, Kay Sievers wrote:
> >
> > > Provide "udevtrigger" program to request events on coldplug. The
> > > shell script is much too slow with thousends of devices.
> > >
> > How does this differ from our "udevplug" ? :)
>
> It simply triggers events for all devices. And the logic to wait for
> the queue to become empty is in a different tool.
>
> > Would it be worth consolidating both into the same tool?
>
> If you can convince me why we would want to filter out events on the
> event generation side instead of doing that on the event handling side.
> I'm not sure about the idea of controlling the module load order or the
> other weird things that way, but you may may have good reasons I don't
> see at the moment.
>
The principal reason for us at the moment is in the initramfs; in the
main system we just plug everything and let the order be damned.
Indeed, wherever we've found a situation where a module load order is
necessary (I know of three or four I think at the moment) we've decided
that the bug is in the driver for requiring that order.
In the initramfs, we exercise a little more caution; making sure that we
only probe PCI IDE or SCSI controllers first before we move on to
probing for USB buses. The reasoning for this is that we don't want
someone's fast USB pen drive beating their SATA or SCSI disk to
getting /dev/sda1
This may be unique to Ubuntu where we try to have an initramfs image
that can do everything, rather than customising it per-install; but then
for us being able to move an installation between machines and have it
always boot has been an important goal.
Scott
--
Scott James Remnant
scott@ubuntu.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: How should I handle binary file with GIT
From: Nicolas Pitre @ 2006-04-05 19:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randal L. Schwartz, git
In-Reply-To: <7vslor27n4.fsf@assigned-by-dhcp.cox.net>
On Wed, 5 Apr 2006, Junio C Hamano wrote:
> If we wanted to use the patch+diff (i.e. "format-patch,
> send-email, and then am" workflow) to transfer new version of
> binary files to a recipient, which I think is useful in some
> projects, the sanest way to handle this is probably to add
> Nico's delta, going from preimage to postimage, encoded for
> safer transport, to our diff output. For safety and sanity, we
> will not "apply" the patch unless the patched file exactly
> matches the preimage that is recorded in the diff, and as long
> as the recipient has the preimage, such a patch would be able to
> reproduce the postimage and hopefully be smaller than
> transferring the whole thing.
Exactly the point.
> We've been trying to keep our diff output reversible (e.g. we
> show what the filemode of the preimage is), so if we take the
> above route, it probably should record deltas for both going
> from preimage to postimage _and_ going the other way (unless
> xdelta can be applied in-reverse, which I do not think is the
> case).
You cannot reverse a delta. However if you were able to apply a delta
from preimage to postimage that means you must already have had preimage
in your object store. Therefore reverting such a patch would simply
involve restoring preimage.
> Of course, to be _completely_ generic, you could include both
> compressed then uuencoded preimage and postimage, and let the
> recipient sort it out.
I think this is just too much and besides the point of a diff. If the
work flow is so convoluted such that the simple binary patch as a delta
doesn't apply then it would probably be a better idea to simply transfer
those binaries as email attachments. In other words, if a binary patch
transfer mechanism is added, it should cover the common case and leave
the rest for a better process like git-fetch/pull.
Nicolas
^ permalink raw reply
* Re: [Xenomai-core] Frozen timer IRQ
From: Jan Kiszka @ 2006-04-05 19:30 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-core
In-Reply-To: <4433C087.3020403@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 2148 bytes --]
Philippe Gerum wrote:
> Philippe Gerum wrote:
>> Gilles Chanteperdrix wrote:
>>
>>> Jan Kiszka wrote:
>>> > Hi,
>>> > > my colleagues and I need some hint where to continue our search
>>> for the
>>> > cause of a weird cleanup issue:
>>> > > An application of our robotics framework sometimes terminates
>>> (though
>>> > successfully) in a way that the system timer IRQ no longer arrives
>>> > afterwards or no re-program takes place anymore. All other Linux IRQs
>>> > are fine (Ethernet, keyboard, etc.). I cannot provide an easy test
>>> case
>>> > yet as besides the framework some expensive gyroscope and the 16550A
>>> > driver are involved.
>>>
>>> I observed a similar issue when xnpod_stop_timer was called when
>>> shutting down the posix skin. I assumed that the problem was that
>>> xnpod_shutdown already called xnpod_stop_timer, so xnpod_stop_timer (and
>>> in particular xnarch_stop_timer) ended up being called twice.
>>>
>>
>> Err, sorry. Forget about my previous reply: xnarch_stop_timer is _not_
>> protected by the XNTIMED flag, but only the last part of the
>> housekeeping chores performed upon stopping the systimer are. IOW,
>> this is a latent bug, and xnpod_stop_timer should be fixed.
>>
>
> Commit 884 should do that.
>
Sorry for replying late: nope, this has no influence on our issue.
Well, someone put that damn piece of hardware on my desk, saying: "It
doesn't work." What he did not say is that there are multiple issues
contained :-/. I found and fixed (patch will follow) a severe bug in the
16550A driver, but the strange timer issue stays (though it's still
tricky to reproduce).
The point is - and that's likely why your patch doesn't help - that we
do not stop the system timer, i.e. unload all skins. We just terminate
an application. I did some research but failed to find a test case (only
our software "manages" to trigger this). Actually, it seems the hardware
timer is no longer working, because also other RT-tasks no longer time
out. Moreover, I checked nkpod->htimer.status, but it remains 0 all the
time. I need more time...
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply
* AVC to Usable messages
From: Daniel J Walsh @ 2006-04-05 19:30 UTC (permalink / raw)
To: Stephen Smalley, SE Linux, Steve Grubb, John Dennis,
Jonathan Blandford
I am adding the capability to analyze AVC messages and allow policy
developers to write a few lines of python that would then "translate"
AVC messages into a human readable sentences. The end goal would be then to
Alert users either through Email for servers or a bugbuddy type
application on the desktop when an AVC message gets delivered.
Each plugin will get called with a list of AVC messages, When it finds
one that it matches, it will strip off the AVC message and return the
translated string. Eventually the second parameter returned by the
plugin, might be a script that the user could then push to rectify the
situation. So we notice that a zone transfer is being attempted to the
system but SELinux is blocking it. Does the user want to allow the zone
transfer? If yes then the "BugBuddy" application will set the boolean
to allow this. (Of course this would all need to authorized).
Example:
time->Wed Apr 5 14:38:38 2006
type=AVC_PATH msg=audit(1144262318.922:237):
path="/usr/lib/flash-plugin/libflashplayer.so"
type=SYSCALL msg=audit(1144262318.922:237): arch=40000003 syscall=125
success=no exit=-13 a0=20f0000 a1=1fd000 a2=5 a3=bfca1260 items=0
pid=2714 auid=3267 uid=3267 gid=3267 euid=3267 suid=3267 fsuid=3267
egid=3267 sgid=3267 fsgid=3267 tty=(none) comm="firefox-bin"
exe="/usr/lib/firefox-1.5.0.1/firefox-bin"
subj=user_u:system_r:unconfined_t:s0-s0:c0.c255
type=AVC msg=audit(1144262318.922:237): avc: denied { execmod } for
pid=2714 comm="firefox-bin" name="libflashplayer.so" dev=dm-0
ino=2803062 scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255
tcontext=system_u:object_r:lib_t:s0 tclass=file
more /usr/share/selinux/plugins/execmod.py
from avc import *
from rhpl.translate import _
def analyze(AVCS):
ret = []
for i in AVCS:
if "execmod" in i["access"]:
if "path" in i:
path=i["path"].strip('"')
else:
path=i["name"].strip('"')
action=(_('An application %s on your system attempted to
load a library %s that needs execmod access. This is a potential
security problem that should be reported as a bugzilla. Most libraries
should not need this access. Somtimes libraries are coded incorrectly
and request this access. You change SELinux to allow the application
this access by executing the following command, "chcon -t
textrel_shlib_t %s"' % (i["comm"], i["name"], path)), "");
ret.append(action)
AVCS.remove(i)
return (ret, AVCS)
audit2allow --analyze -i /var/log/audit/audit.log
An application "firefox-bin" on your system attempted to load a library
"libflashplayer.so" that needs execmod access. This is a potential
security problem that should be reported as a bugzilla. Most libraries
should not need this access. Somtimes libraries are coded incorrectly
and request this access. You change SELinux to allow the application
this access by executing the following command, "chcon -t
textrel_shlib_t /usr/lib/flash-plugin/libflashplayer.so"
Thoughts?
Dan
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: : IA64 ISOs based on Fedora Core 5
From: David Woodhouse @ 2006-04-05 19:30 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <20060405163521.GS30438@neu.nirvana>
On Wed, 2006-04-05 at 18:35 +0200, Axel Thimm wrote:
> > Aside from the updates, the next task is building Extras and Livna
> > for IA64, of course...
>
> and who's going to do ATrpms? ;)
ATrpms hasn't even caught up with the platform support we had in the
final release of FC4 yet -- I don't think there's any need to worry
about building for IA64 for now.
--
dwmw2
^ permalink raw reply
* Error getting VM-informations with Python on Xen 3.0.2
From: Thorolf Godawa @ 2006-04-05 19:24 UTC (permalink / raw)
To: xen-devel
Hi all,
I wrote a small python-script to monitor the status of the started VMs
based on the xenmon.py and the following code I got from Anthony Liguori:
----------------------------------------
import sys
sys.path.append('/usr/lib/python')
sys.path.append('/usr/lib64/python')
from xen.xend.XendClient import server
from xen.xend import sxp
def parse_doms_info(info):
def get_info(n, t, d):
return t(sxp.child_value(info, n, d))
return {
'dom' : get_info('domid', int, -1),
'name' : get_info('name', str, '??'),
'mem' : get_info('memory', int, 0),
'vcpus' : get_info('online_vcpus', int, 0),
'state' : get_info('state', str, '??'),
'cpu_time' : get_info('cpu_time', float, 0),
'ssidref' : get_info('ssidref', int, 0),
}
doms = server.xend_list_domains()
print 'Name ID Mem(MiB) VCPUs State Time(s)'
for dom in doms:
d = parse_doms_info(dom)
if (d['ssidref'] != 0):
d['ssidstr'] = (" s:%04x/p:%04x" %
((d['ssidref'] >> 16) & 0xffff,
d['ssidref'] & 0xffff))
else:
d['ssidstr'] = ""
print ("%(name)-32s %(dom)3d %(mem)8d %(vcpus)5d %(state)5s%
(cpu_time)7.1f% (ssidstr)s" % d)
----------------------------------------
I wrote the script on SUSE SLES 10.0 Beta 3 with Xen 3.0_8659-2.
Unfortunately this script (and therefor my one too) ist not running
anymore with the latest SUSE SLES 10.0 Beta 9 that includes Xen
3.0.2_09434-2 :-(
It breaks at line "doms = server.xend_list_domains()" with the following
error:
----------------------------------------
Traceback (most recent call last):
File "xentest1.py", line 22, in ?
doms = server.xend_list_domains()
File "/usr/lib/python2.4/xmlrpclib.py", line 1096, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request
verbose=self.__verbose
File "/usr/lib/python2.4/site-packages/xen/util/xmlrpclib2.py", line
46, in request
return Transport.request(self, host, '/RPC2', request_body, verbose)
File "/usr/lib/python2.4/xmlrpclib.py", line 1147, in request
return self._parse_response(h.getfile(), sock)
File "/usr/lib/python2.4/xmlrpclib.py", line 1286, in _parse_response
return u.close()
File "/usr/lib/python2.4/xmlrpclib.py", line 744, in close
raise Fault(**self._stack[0])
xmlrpclib.Fault: <Fault 1: 'Traceback (most recent call last):\n File
"/usr/lib/python2.4/site-packages/xen/util/xmlrpclib2.py", line 74, in
_marshaled_dispatch\n response = self._dispatch(method, params)\n
File "/usr/lib/python2.4/SimpleXMLRPCServer.py", line 408, in
_dispatch\n raise Exception(\'method "%s" is not supported\' %
method)\nException: method "xend_list_domains" is not supported\n'>
----------------------------------------
If I see right it now uses "/usr/lib/python2.4/SimpleXMLRPCServer.py"
(what does not exist in Xen 3.0_8659-2) and breaks because the method
"xend_list_domains" is not supported anymore I use to get the
domain-informations with the script.
Is there a better way to get the VM-status like name, memory, state,
CPU-usage etc. via Python than using the mechanism from xenmon.py and
the above one?
Thanks a lot for your answers,
--
Chau y hasta luego,
Thorolf
------------------------------------------------------------------
e-Mail: mailto:Thorolf@Godawa.de \|/
/'~'\
Homepage: http://www.godawa.de ( o o )
--------------------------------------------------oOOO--(_)--OOOo-\x1a
^ permalink raw reply
* Error getting VM-informations with Python on Xen 3.0.2
From: Thorolf Godawa @ 2006-04-05 19:24 UTC (permalink / raw)
To: xen-devel
Hi all,
I wrote a small python-script to monitor the status of the started VMs
based on the xenmon.py and the following code I got from Anthony Liguori:
----------------------------------------
import sys
sys.path.append('/usr/lib/python')
sys.path.append('/usr/lib64/python')
from xen.xend.XendClient import server
from xen.xend import sxp
def parse_doms_info(info):
def get_info(n, t, d):
return t(sxp.child_value(info, n, d))
return {
'dom' : get_info('domid', int, -1),
'name' : get_info('name', str, '??'),
'mem' : get_info('memory', int, 0),
'vcpus' : get_info('online_vcpus', int, 0),
'state' : get_info('state', str, '??'),
'cpu_time' : get_info('cpu_time', float, 0),
'ssidref' : get_info('ssidref', int, 0),
}
doms = server.xend_list_domains()
print 'Name ID Mem(MiB) VCPUs State Time(s)'
for dom in doms:
d = parse_doms_info(dom)
if (d['ssidref'] != 0):
d['ssidstr'] = (" s:%04x/p:%04x" %
((d['ssidref'] >> 16) & 0xffff,
d['ssidref'] & 0xffff))
else:
d['ssidstr'] = ""
print ("%(name)-32s %(dom)3d %(mem)8d %(vcpus)5d %(state)5s%
(cpu_time)7.1f% (ssidstr)s" % d)
----------------------------------------
I wrote the script on SUSE SLES 10.0 Beta 3 with Xen 3.0_8659-2.
Unfortunately this script (and therefor my one too) ist not running
anymore with the latest SUSE SLES 10.0 Beta 9 that includes Xen
3.0.2_09434-2 :-(
It breaks at line "doms = server.xend_list_domains()" with the following
error:
----------------------------------------
Traceback (most recent call last):
File "xentest1.py", line 22, in ?
doms = server.xend_list_domains()
File "/usr/lib/python2.4/xmlrpclib.py", line 1096, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request
verbose=self.__verbose
File "/usr/lib/python2.4/site-packages/xen/util/xmlrpclib2.py", line
46, in request
return Transport.request(self, host, '/RPC2', request_body, verbose)
File "/usr/lib/python2.4/xmlrpclib.py", line 1147, in request
return self._parse_response(h.getfile(), sock)
File "/usr/lib/python2.4/xmlrpclib.py", line 1286, in _parse_response
return u.close()
File "/usr/lib/python2.4/xmlrpclib.py", line 744, in close
raise Fault(**self._stack[0])
xmlrpclib.Fault: <Fault 1: 'Traceback (most recent call last):\n File
"/usr/lib/python2.4/site-packages/xen/util/xmlrpclib2.py", line 74, in
_marshaled_dispatch\n response = self._dispatch(method, params)\n
File "/usr/lib/python2.4/SimpleXMLRPCServer.py", line 408, in
_dispatch\n raise Exception(\'method "%s" is not supported\' %
method)\nException: method "xend_list_domains" is not supported\n'>
----------------------------------------
If I see right it now uses "/usr/lib/python2.4/SimpleXMLRPCServer.py"
(what does not exist in Xen 3.0_8659-2) and breaks because the method
"xend_list_domains" is not supported anymore I use to get the
domain-informations with the script.
Is there a better way to get the VM-status like name, memory, state,
CPU-usage etc. via Python than using the mechanism from xenmon.py and
the above one?
Thanks a lot for your answers,
--
Chau y hasta luego,
Thorolf
^ permalink raw reply
* Re: How should I handle binary file with GIT
From: Marco Roeland @ 2006-04-05 19:23 UTC (permalink / raw)
To: moreau francis; +Cc: Junio C Hamano, git
In-Reply-To: <20060405131834.60888.qmail@web25804.mail.ukl.yahoo.com>
On Wednesday April 5th 2006 moreau francis wrote:
> BTW, what does "--amend" option do ? It doesn't seem to be documented anywhere.
This is the original commit text that introduced it:
diff-tree b4019f045646b1770a80394da876b8a7c6b8ca7b (from d320a5437f8304cf9ea3ee1898e49d643e005738)
Author: Junio C Hamano <junkio@cox.net>
Date: Thu Mar 2 21:04:05 2006 -0800
git-commit --amend
The new flag is used to amend the tip of the current branch. Prepare
the tree object you would want to replace the latest commit as usual
(this includes the usual -i/-o and explicit paths), and the commit log
editor is seeded with the commit message from the tip of the current
branch. The commit you create replaces the current tip -- if it was a
merge, it will have the parents of the current tip as parents -- so the
current top commit is discarded.
It is a rough equivalent for:
$ git reset --soft HEAD^
$ ... do something else to come up with the right tree ...
$ git commit -c ORIG_HEAD
but can be used to amend a merge commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
So in the original context you can add separate binaries to a commit
of only text files that you just rescued from CVS or something and then
change the commit to include these binaries as well.
I've sent a separate patch for the documentation for git-commit using
Junio's clear explanation.
--
Marco Roeland
^ permalink raw reply
* [Qemu-devel] qemu-0.8.0 and vde-1.5.9 question
From: Ishwar Rattan @ 2006-04-05 19:25 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <44285974.9040003@bellard.org>
The system is Kanotix-2005-4
Qemu-0.8.0
Vde-1.5.9
I setup the bridge and add interface tun0 to the bridge
(have done it before correctly)
but
/usr/bin/vdeqemu -hda disk-image -m256 -localtime -net vde -net nic,macaddr=54:52:00:12:34:62
reports error:
qemu: invalid option -- '-tun-fd'
qemu exited: vdeqemu quits
I seem to reacall that it worked with qemu-0.7.2 ?
Any ideas?
-ishwar
^ permalink raw reply
* Re: [uml-devel] system call accessing the host os
From: Jeff Dike @ 2006-04-05 18:18 UTC (permalink / raw)
To: Olivier Crameri; +Cc: user-mode-linux-devel
In-Reply-To: <8F963598-0F1A-464A-991A-2FE95F9B418C@epfl.ch>
On Wed, Apr 05, 2006 at 07:16:22PM +0200, Olivier Crameri wrote:
> Unfortunately, I'm having some weird issues that I can't really
> understand. I can read the file using fread, but only in a buffer
> that I allocated using um_kmalloc. If I use a buffer allocated by
> malloc, the fread fails. Then, even if I replace all my mallocs by
> um_kmallocs, some libc functions (such as sscanf) don't seem to work
> properly. I guess I'm missing something, but I can't figure out what.
Define "fails" and "don't seem to work properly".
If your buffers are larger than 128K, then libc malloc gets turned into
UML kernel vmalloc. In this case, the buffer isn't mapped, and
passing it into a system call will make it return -EFAULT. The
easiest workaround for this is to memset the thing immediately after
allocating it.
Also, if you're using the libc things you're talking about, watch out
for your stack consumption. By default, you get two pages (8K).
printf will completely use it up, so it is unusable in kernel code.
UML kernel stack size is configurable - CONFIG_KERNEL_STACK_ORDER -
bumping that to 3 will double the kernel stack size. If problems then
go away, then you know that libc is overflowing your stack.
Jeff
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* [PATCH] git-commit: document --append
From: Marco Roeland @ 2006-04-05 19:16 UTC (permalink / raw)
To: git
The "--amend" option is used to amend the tip of the current branch. This
documentation text was copied straight from the commit that implemented it.
Signed-off-by: Marco Roeland <marco.roeland@xs4all.nl>
---
Documentation/git-commit.txt | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
ca7d3b4fdd0cb24b7353da312fb9306531468f54
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index d04b342..3701cb3 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -9,7 +9,8 @@ SYNOPSIS
--------
[verse]
'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]
- [-e] [--author <author>] [--] [[-i | -o ]<file>...]
+ [--no-verify] [--amend] [-e] [--author <author>]
+ [--] [[-i | -o ]<file>...]
DESCRIPTION
-----------
@@ -70,6 +71,25 @@ OPTIONS
`-m`, and from file with `-C` are usually used as the
commit log message unmodified. This option lets you
further edit the message taken from these sources.
+
+--amend::
+
+ Used to amend the tip of the current branch. Prepare the tree
+ object you would want to replace the latest commit as usual
+ (this includes the usual -i/-o and explicit paths), and the
+ commit log editor is seeded with the commit message from the
+ tip of the current branch. The commit you create replaces the
+ current tip -- if it was a merge, it will have the parents of
+ the current tip as parents -- so the current top commit is
+ discarded.
+
+ It is a rough equivalent for:
+
+ $ git reset --soft HEAD^
+ $ ... do something else to come up with the right tree ...
+ $ git commit -c ORIG_HEAD
+
+ but can be used to amend a merge commit.
-i|--include::
Instead of committing only the files specified on the
--
1.3.0.rc2.gca38
^ permalink raw reply related
* В аренду офис в бизнес-центре класса «В+» м. Павелецкая
From: Tampering H. Overdraft @ 2006-04-05 19:19 UTC (permalink / raw)
To: Linux
яю\x12\x04
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: udev, PROGRAM and races...
From: Andrey Borzenkov @ 2006-04-05 19:10 UTC (permalink / raw)
To: J.A. Magallon; +Cc: linux-kernel, oblin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> This is done with rule like:
>
> SUBSYSTEM=="block", ACTION=="add", ENV{ID_CDROM}=="?*", \
> PROGRAM="/lib/udev/udev_cdrom_helper", SYMLINK+="%c"
>
> This helper tries to get the next free %d index to create cdrom%d, for
> example.
> The problem is that the launch of both helpers for hda and add seems to be
> done in parallel and the helper gets racy, so both cdroms get id 0, and the
> last that comes owns it:
>
> helper instance for hda helper instance for hdd
> Does cdrom0 exist ? No
> Does cdrom0 exist ? No
> ln -sf hda cdrom0
> ln -sf hdd cdrom0
>
> ????
>
Do you have real example of race condition?
> Is there any way to serialize the calls to 'PROGRAM'. I tried something
> like:
>
> SUBSYSTEM=="block", ACTION=="add", ENV{ID_CDROM}=="?*",
> PROGRAM="/usr/bin/flock /sys/block /lib/udev/udev_cdrom_helper",
> SYMLINK+="%c"
>
> But looks a lot ugly.
>
Why? It is probably the simplest fix actually (assuming sysfs does support
locking, I am not sure).
> Any standard way to do this ?
I never liked this automatic creation of symlinks, I believe this has to be
done as part of device configuration (harddrake on distro you likely mean :)
> Can I still use %e, or is it really really deprecated ? this was easy:
>
> ENV{ID_CDROM_CD_RW}=="?*", SYMLINK+="burner%e", MODE="0666",
> GROUP="cdwriter" ENV{ID_CDROM_DVD_R}=="?*", SYMLINK+="burner%e",
> MODE="0666", GROUP="cdwriter"
Yes it is deprecated exactly for the same reason. What ensures uniqueness of
%e?
regards
- -andrey
PS I believe it is more appropriate for distro-specific list actually.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFENBYWR6LMutpd94wRAk4qAJoDaSaLY4nDCgif0ybFdumc2Q7NzACgvo1n
U6fB7VUhQ70FG4nql8a6Nwk=
=fnir
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: FAQ entry for loopback mounting
From: Jörn Engel @ 2006-04-05 19:05 UTC (permalink / raw)
To: Ralph Siemsen; +Cc: linux-mtd, David Woodhouse
In-Reply-To: <44340038.3000602@netwinder.org>
On Wed, 5 April 2006 13:36:56 -0400, Ralph Siemsen wrote:
> David Woodhouse wrote:
>
> >We _are_ being lenient. If you say 'k' or 'M' instead of 'Ki' or 'Mi'
> >then you are going to get the powers of ten which you asked for... which
> >is almost certainly _not_ what you wanted. Giving you powers of two is
> >not an option. So it's best not to accept it at all.
>
> No, if you give it "k" only, then it multiples by 1024, but because
> there is no "i", it does not advance *endp, and then parse_num() returns
> -EINVAL because it sees trailing garbage. So just "k" is not accepted
> at all, which is not "leniant" in my books.
Well, we have the following options:
1) accept "k" only, interpret as 1024
2) accept both "k" and "ki", interpret as 1024
3) accept "k" and interpret as 1000, accept "ki" and interpret as 1024
4) accept "ki" only, interpret as 1024
Option 1 is what has been done by every piece of software for years.
People are used to it. But it also causes confusion at time. For
example, my 40GB hard disk is only 37GiB in size. Hard disk
manufacturers _do_ mean 1000*1000*1000 when talking about GB. DRAM
manufacturers mean 1024*1024*1024 when talking about GB. GBit
ethernet means 1000MBit. 10MBit might mean 10*1024*1024, not sure
about that.
Ergo: It is confusing, don't do it.
Option 2 has all the disadvantages of 1.
Ergo: It is confusing, don't do it.
Option 3 will cause many people to expect "k" to be interpreted as
1024, while something completely different happens.
Ergo: It is confusing, don't do it.
Option 4 simply doesn't accept "k". People used to it will have to
stop and think, then notice that it is called "ki" now and definitely
means 1024, even when talking about hard disks, ethernet, etc.
Ergo: Initial surprise, but after that the interface does what one
expects.
I personally don't like solution 4 too much either. But it is much
better than the other three. And the "but this is flash, so in this
particular case everyone knows it means 1024" argument simply doesn't
work. If you look at the FAQ section of your favorite computer
magazine, you see the "why is my 40GB hard disk only 37GiB in size"
question in it. People don't know when "k" means 1000 and when it
means 1024.
If you have a better solution, though, I'm all yours. ;)
Jörn
--
I've never met a human being who would want to read 17,000 pages of
documentation, and if there was, I'd kill him to get him out of the
gene pool.
-- Joseph Costello
^ permalink raw reply
* Re: mem= causes oops (was Re: BIOS causes (exposes?) modprobe (load_module) kernel oops)
From: Randy.Dunlap @ 2006-04-05 19:07 UTC (permalink / raw)
To: jzb; +Cc: linux-kernel
In-Reply-To: <200603251036.40379.jzb@aexorsyst.com>
On Sat, 25 Mar 2006 10:36:40 -0800 John Z. Bohach wrote:
> On Friday 24 March 2006 16:32, Randy.Dunlap wrote:
> > > Here it is:
> > >
> > > fails with cmdline:
> > >
> > > Kernel command line: ro root=/dev/sda1 rootdelay=10 mem=0x200M
> > > console=ttyS0,115200n8
> > >
> > > works with:
> > >
> > > Kernel command line: ro root=/dev/sda1 rootdelay=10
> > > console=ttyS0,115200n8
> > >
> > > Note the "mem=" being the differentiator!
> >
> > OK, that is memory map difference.
> >
> > Can you test a more recent kernel to see if it has the same problem?
> > (like 2.6.16 or 2.6.16-git9)
>
> No luck, or difference, for that matter. 2.6.16 behaves identically. I'm
> trying a few different options, such as disabling MSI/MSI-X support,
> because what I've seen is that it all works fine with it as long as the h/w
> has MSI support, but in all the case I've seen fail, the common denominator
> is no MSI (and also all ICH4 platforms). The cases where I can't make it fail
> is where the h/w has MSI support. One other noteworthy difference is that the
> failures all occur on Intel graphics chipsets, while the successes are non-graphics.
> Still trying to find out whether the failure follows graphics or the ICH4.
>
> Anyway, what would help me is if someone could tell me if the page fault is a normal and
> expected code path by design, in order to page in the area setup by __vmalloc_area()
> as triggered by the module_alloc() call. I'd really rather not have to trace through the
> page fault handler to identify the difference between success/failure unless I have to.
AFAIK the page fault is not expected, but I would be happier if someone else
confirmed that.
BTW, Documentation/kernel-parameters.txt suggests using mem= and memmap=
together, so maybe you could use memmap=.... to prevent this problem.
---
~Randy
^ permalink raw reply
* Re: [2.6.17-rc1] ALSA oops with multiple OSS clients
From: Luca Tettamanti @ 2006-04-05 19:03 UTC (permalink / raw)
To: Lee Revell; +Cc: linux-kernel, perex, alsa-devel
In-Reply-To: <1144259073.10626.2.camel@mindpipe>
On 4/5/06, Lee Revell <rlrevell@joe-job.com> wrote:
> On Wed, 2006-04-05 at 19:30 +0200, Luca wrote:
> > Hello,
> > I've a reproducible OOPS when starting multiple OSS clients.
> > To reproduce I do this:
> > mpg123 song.mp3
> > mpg123 song.mp3 (another time)
> >
> > At this point the song restart from the beginning (i.e. I think that
> > the second mpg123 takes over the device). When the second instance
> > terminates the song I get the following OOPS:
>
> Known bug, please try the patch:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6329
The patch works fine.
thanks,
Luca
^ permalink raw reply
* Re: udev 085 warnings
From: Kay Sievers @ 2006-04-05 19:03 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <Pine.LNX.4.61.0604051110170.11179@yvahk01.tjqt.qr>
On Wed, Apr 05, 2006 at 11:10:40AM +0200, Jan Engelhardt wrote:
> I am currently compiling udev-085-14.src.rpm from the opensuse OSS-factory
> tree on a 64-bit arch and get a lot of these warnings:
>
> fat.c:325: warning: cast increases required alignment of target type
> 325:
> next = le32_to_cpu(*((uint32_t *) buf) & 0x0fffffff);
>
> Will there be a proper fix or is this just another of these nice gcc
> warnings that are superfluous?
GCC is correct warning about that, cause the Makefile asked for that
kind of warning. The buffer access is always aligned but the compiler
can't know that. To get rid of it, you would need to memcpy() the integer
in a variable or access it byte by byte and shift it to an integer
value. Removing -Wcast-align should be the easiest. :)
Kay
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: [stable] Re: [PATCH] isd200: limit to BLK_DEV_IDE
From: Randy.Dunlap @ 2006-04-05 19:04 UTC (permalink / raw)
To: Greg KH; +Cc: beber.lkml, beber, gregkh, linux-kernel, torvalds, stable
In-Reply-To: <20060405184532.GA2577@kroah.com>
On Wed, 5 Apr 2006 11:45:32 -0700 Greg KH wrote:
> On Wed, Apr 05, 2006 at 03:35:38PM +0200, Beber wrote:
> > On 3/31/06, Bertrand Jacquin <beber@gna.org> wrote:
> > > Le Thu, 30 Mar 2006 14:35:26 -0800 (PST), "Randy.Dunlap" <rdunlap@xenotime.net> m'a avou?:
> > >
> > > > On Thu, 30 Mar 2006, Beber wrote:
> > > >
> > > > > On 3/28/06, Greg KH <gregkh@suse.de> wrote:
> > > > > > We (the -stable team) are announcing the release of the 2.6.16.1 kernel.
> > > > >
> > > > > I still get this error :
> > > > >
> > > > > # make
> > > > ...
> > > > > drivers/built-in.o: In function `isd200_Initialization':
> > > > > : undefined reference to `ide_fix_driveid'
> > > > > make: *** [.tmp_vmlinux1] Error 1
> > > >
> > > > Was this reported earlier?
> > >
> > > Yes, it was, but ignored, so I repost it ;)
> > >
> > > > Please test the patch below.
> > > > It works for me with your config and various others.
> > >
> > > It work here too.
> > > Thanks
> >
> > I look on last GIT history and didn't find this applyed upstream. Will it be ?
>
> No one has forwarded it to the stable group, so it's a bit hard to apply
> it to the tree if that doesn't happen :)
ok, I just did that...
---
~Randy
^ permalink raw reply
* [PATCH] isd200: limit to BLK_DEV_IDE
From: Randy.Dunlap @ 2006-04-05 19:03 UTC (permalink / raw)
To: stable, lkml
From: Randy Dunlap <rdunlap@xenotime.net>
Limit USB_STORAGE_ISD200 to whatever BLK_DEV_IDE and USB_STORAGE
are set to (y, m) since isd200 calls ide_fix_driveid() in the
BLK_DEV_IDE code.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
drivers/usb/storage/Kconfig | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
--- linux-2616-z.orig/drivers/usb/storage/Kconfig
+++ linux-2616-z/drivers/usb/storage/Kconfig
@@ -48,7 +48,8 @@ config USB_STORAGE_FREECOM
config USB_STORAGE_ISD200
bool "ISD-200 USB/ATA Bridge support"
- depends on USB_STORAGE && BLK_DEV_IDE
+ depends on USB_STORAGE
+ depends on BLK_DEV_IDE=y || BLK_DEV_IDE=USB_STORAGE
---help---
Say Y here if you want to use USB Mass Store devices based
on the In-Systems Design ISD-200 USB/ATA bridge.
---
^ permalink raw reply
* Re: [PATCH] Convert OSS aic23 to mutex
From: Paul Mundt @ 2006-04-05 19:00 UTC (permalink / raw)
To: Dirk Behme; +Cc: linux-omap-open-source
In-Reply-To: <443407FB.2060304@gmail.com>
On Wed, Apr 05, 2006 at 08:10:03PM +0200, Dirk Behme wrote:
> --- ./sound/oss/omap-audio-aic23.c_orig 2006-04-05 20:02:22.000000000 +0200
> +++ ./sound/oss/omap-audio-aic23.c 2006-04-05 20:03:05.000000000 +0200
> @@ -243,7 +243,7 @@ static audio_state_t aic23_state = {
> .hw_remove = __exit_p(omap_aic23_remove),
> .hw_suspend = omap_aic23_suspend,
> .hw_resume = omap_aic23_resume,
> - .sem = __SEMAPHORE_INIT(aic23_state.sem, 1),
> + .mutex = __MUTEX_INITIALIZER(aic23_state.mutex),
> };
>
> /* This will be defined in the audio.h */
>
Are you sure this doesn't need an #include <linux/mutex.h>? All of the
other conversions so far have..
^ permalink raw reply
* [U-Boot-Users] [PATCH] objcopy for srec and bin files should be done on .o files
From: Martin Hicks @ 2006-04-05 18:59 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20060405183323.7A688352664@atlas.denx.de>
On Wed, Apr 05, 2006 at 08:33:23PM +0200, Wolfgang Denk wrote:
> In message <20060405162645.GU27792@bork.org> you wrote:
> >
> > The Makefile rule for creating srec and bin files fails for me frequently.
>
> Plewase explain what "fails for me means" (error message(s), used
> toolchain and versions of the binutils, host environment etc.).
mort at descartes:~/src/targa/u-boot2$ make ASH405_config CROSS_COMPILE=powerpc-405-linux-gnu-
Configuring for ASH405 board...
mort at descartes:~/src/targa/u-boot2$ make CROSS_COMPILE=powerpc-405-linux-gnu-
[snip]
powerpc-405-linux-gnu-gcc -g -Os -fPIC -ffixed-r14 -meabi -fno-strict-aliasing -D__KERNEL__ -DTEXT_BASE=0xFFFC0000 -I/home/mort/src/targa/u-boot2/include -fno-builtin -ffreestanding -nostdinc -isystem /home/mort/src/targa/powerpc-linux/gcc-3.4.5-glibc-2.3.6/powerpc-405-linux-gnu/bin/../lib/gcc/powerpc-405-linux-gnu/3.4.5/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -ffixed-r2 -ffixed-r29 -mstring -Wa,-m405 -mcpu=405 -msoft-float -Wall -Wstrict-prototypes -c -o stubs.o stubs.c
powerpc-405-linux-gnu-ar crv libstubs.a ppc_longjmp.o ppc_setjmp.o stubs.o
r - ppc_longjmp.o
r - ppc_setjmp.o
r - stubs.o
make[1]: *** No rule to make target `hello_world.srec', needed by `all'. Stop.
make[1]: Leaving directory `/home/mort/src/targa/u-boot2/examples'
make: *** [examples] Error 2
mort at descartes:~/src/targa/u-boot2$
That's your git HEAD. The problem is also present at the 1.1.4 tag.
I"m not actually using the ASH405, but I just used it as an example...
The compiler is a gcc-3.4.5/binutils-2.15 (and glibc-2.3.6) x86->ppc405
cross compiler built by crosstools-0.42
mh
--
Martin Hicks || mort at bork.org || PGP/GnuPG: 0x4C7F2BEE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20060405/312ee1ed/attachment.pgp
^ permalink raw reply
* Re: [stable] Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)
From: Greg KH @ 2006-04-05 18:52 UTC (permalink / raw)
To: Jon Smirl; +Cc: Sergey Vlasov, gregkh, linux-kernel, stable
In-Reply-To: <9e4733910604050830x2daf2ec1vd1fe16073b51de8c@mail.gmail.com>
On Wed, Apr 05, 2006 at 11:30:54AM -0400, Jon Smirl wrote:
>
> The one attribute per file model doesn't work well when the attributes
> need to be changed in a transaction. For example you want to change
> your display to 1024x768 16bit color. As you set the attributes one
> at a time the display has to change since there is not guarantee that
> you will complete the sequence. The framebuffer sysfs interface breaks
> the one attribute per file rule and uses strings for grouped
> attributes.
I suggest you use configfs instead for this. It allows this kind of
"grouped attributes".
good luck,
greg k-h
^ 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.