The below implements the getgeo hook for Xen block devices. Extracted
from the xen-unstable tree where it has been used for ages.
It is useful to have because it allows things like grub2 (used by the
Debian installer images) to work in a guest domain without having to
sprinkle Xen specific hacks around the place.
Signed-off-by: Ian Campbell <[email protected]>
From: Ian Campbell <[email protected]>
Signed-off-by: Jeremy Fitzhardinge <[email protected]>
---
drivers/block/xen-blkfront.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
===================================================================
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -37,6 +37,7 @@
#include <linux/interrupt.h>
#include <linux/blkdev.h>
+#include <linux/hdreg.h>
#include <linux/module.h>
#include <xen/xenbus.h>
@@ -134,6 +135,22 @@ static void blkif_restart_queue_callback
{
struct blkfront_info *info = (struct blkfront_info *)arg;
schedule_work(&info->work);
+}
+
+int blkif_getgeo(struct block_device *bd, struct hd_geometry *hg)
+{
+ /* We don't have real geometry info, but let's at least return
+ values consistent with the size of the device */
+ sector_t nsect = get_capacity(bd->bd_disk);
+ sector_t cylinders = nsect;
+
+ hg->heads = 0xff;
+ hg->sectors = 0x3f;
+ sector_div(cylinders, hg->heads * hg->sectors);
+ hg->cylinders = cylinders;
+ if ((sector_t)(hg->cylinders + 1) * hg->heads * hg->sectors < nsect)
+ hg->cylinders = 0xffff;
+ return 0;
}
/*
@@ -946,6 +963,7 @@ static struct block_device_operations xl
.owner = THIS_MODULE,
.open = blkif_open,
.release = blkif_release,
+ .getgeo = blkif_getgeo,
};
On Thu, 21 Feb 2008, Jeremy Fitzhardinge wrote:
>
> Signed-off-by: Ian Campbell <[email protected]>
> From: Ian Campbell <[email protected]>
> Signed-off-by: Jeremy Fitzhardinge <[email protected]>
This is just wrong. The From: goes at the *top*, and if it's not there,
my scripts won't pick it up as the author.
Linus
Linus Torvalds wrote:
> On Thu, 21 Feb 2008, Jeremy Fitzhardinge wrote:
>
>> Signed-off-by: Ian Campbell <[email protected]>
>> From: Ian Campbell <[email protected]>
>> Signed-off-by: Jeremy Fitzhardinge <[email protected]>
>>
>
> This is just wrong. The From: goes at the *top*, and if it's not there,
> my scripts won't pick it up as the author.
OK. Have you fixed it, or shall I resend?
Thanks,
J
On Thu, 21 Feb 2008, Jeremy Fitzhardinge wrote:
>
> OK. Have you fixed it, or shall I resend?
I'll fix it, but I want people to know so that I don't have to fix things
like this in the future (*).
Linus
(*) I keed, I keed. Of *course* I'll have to fix things like this in the
future too. But hopefully not quite as often.
Linus Torvalds wrote:
> On Thu, 21 Feb 2008, Jeremy Fitzhardinge wrote:
>
>> OK. Have you fixed it, or shall I resend?
>>
>
> I'll fix it, but I want people to know so that I don't have to fix things
> like this in the future (*).
>
> Linus
>
> (*) I keed, I keed. Of *course* I'll have to fix things like this in the
> future too. But hopefully not quite as often.
>
Putting the From: in the Signed-off-by block is a result of two thoughts:
1. putting it at the top makes the most sense from an email
perspective, but it often seem to get lost by various
patch-posting programs if it gets tangled in the Subject/summary
part of the patch. The result is that it needs to float in an odd
way:
Subject: wooble the foo
From: Foo Woobler <[email protected]>
Wooble foos in the appropriate manner.
Signed-off-by: Foo Woobler <[email protected]>
Cc: Bar Mangler <[email protected]>
2. There's already a block of email addresses which describe how
people relate to this patch, so why not put From: there (since it
isn't really an email From header, but a patch metadata header).
I'd assumed that tools which pick "Thing: Email" pairs out of a
patch would deal with From in the same place as a Signed-off-by.
After all, tools deal with Cc:s there.
I'll make sure From: is in the right place in future, but I just wanted
to point out it wasn't complete randomness.
J
Jeremy Fitzhardinge <[email protected]> writes:
> Putting the From: in the Signed-off-by block is a result of two thoughts:
>
> 1. putting it at the top makes the most sense from an email
> perspective, but it often seem to get lost by various
> patch-posting programs if it gets tangled in the Subject/summary
> part of the patch. The result is that it needs to float in an odd
> way:
>
> Subject: wooble the foo
>
> From: Foo Woobler <[email protected]>
>
> Wooble foos in the appropriate manner.
>
> Signed-off-by: Foo Woobler <[email protected]>
> Cc: Bar Mangler <[email protected]>
>
> 2. There's already a block of email addresses which describe how
> people relate to this patch,...
In addition to "From: ", you can place "Subject: " and "Date: "
at the beginning to make sure Linus or whoever applies patches
would not get the authorship information from the e-mail itself
you send (this is especially true when you are forwarding
somebody else's patch).
Mnemonic is that the equivalents to E-mail headers go at the
top. You will never have Signed-off-by:, Tested-by:, nor
Acked-by: in your e-mail headers. They go at the bottom.
This is just a toolsmith speaking, I am not in any way
trying to set a policy for this list.
I do not know where that Cc: near S-o-b: comes from, though. It
is not accepted at the top as there is no place for such an
information in commits.
Linus Torvalds <[email protected]> writes:
>
> (*) I keed, I keed. Of *course* I'll have to fix things like this in the
> future too. But hopefully not quite as often.
The pragmatic solution would be to just fix the scripts to accept From
everywhere @)
-Andi
On Fri, 22 Feb 2008, Andi Kleen wrote:
>
> Linus Torvalds <[email protected]> writes:
> >
> > (*) I keed, I keed. Of *course* I'll have to fix things like this in the
> > future too. But hopefully not quite as often.
>
> The pragmatic solution would be to just fix the scripts to accept From
> everywhere @)
I worry about that. We've actually had to tighten up the scripts over time
to not assign meaning to things, because people put various things in the
free-form descriptions, and it's really bad to corrupt the description.
This isn't a problem with things like "Signed-off-by:" etc tags, because
they have no automated meaning and don't really change the commit itself,
but the "From:"/"Date:"/"Subject:" markers at the head of the message
really do have real meaning, and get removed from the commit message and
instead get put into the SCM headers.
So I'd rather have the rules be very strict and not cause any surprises,
than have loose rules and then occasionally an email has a "From:" in the
middle and my scripts get all confused.
It's not a *huge* problem, and my gut feel is that it's getting rarer as
people learn. Rigth now we have about 86,000 commits in the mainline git
history, and 807 (less than 1%) of those have a 'From:' in the message.
And in many cases, that "From:" was at the head, so there are simply
people who do not *use* the standard scripts and making the scripts accept
it everywhere wouldn't have helped anyway!
And in the great majority of cases - at least the ones I looked at -
authorship actually got attributed correctly. And in some of the cases,
the "From:" really *was* part of the message, and removing it would have
been wrong. See for example 22e78fafbdf84883f70eb4944cf658fc23c4a1f4 where
the From: was about an email exchange (it gave the rigth author anyway,
but without that line the commit message would have made less sense).
There are a few other cases with "From:" in the middle, where the From:
doesn't mean authorship (but attributes fixes to the patch, for example).
It's admittedly fairly rare, but it shows that it happens (I found
something like four occurrences of that before I got too bored).
Linus
Linus Torvalds wrote:
> This isn't a problem with things like "Signed-off-by:" etc tags, because
> they have no automated meaning and don't really change the commit itself,
> but the "From:"/"Date:"/"Subject:" markers at the head of the message
> really do have real meaning, and get removed from the commit message and
> instead get put into the SCM headers.
>
It may be worth having a definitive and unambiguous Author: tag then,
which can appear among Signed-off-by:s and is used in preference to
anything else. From: is a useful heuristic which seems to work well in
general, but as you say, it gets a bit hairy when you have something
which means different things to different parts of the software stack at
the same time.
J