* Re: Funny repack behaviour
From: Johannes Schindelin @ 2006-04-08 22:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604081528070.2215@localhost.localdomain>
Hi,
On Sat, 8 Apr 2006, Nicolas Pitre wrote:
> On Sat, 8 Apr 2006, Johannes Schindelin wrote:
>
> > Hi,
> >
> > I just accidentally reran "git-repack -a -d" on a repository, where I just
> > had run it. And I noticed a funny thing: Of about 4000 objects, it reused
> > all but 8. So I reran it, and it reused all but 2. I ran it once again,
> > and it reused all.
> >
> > The really funny thing is: it created the same pack every time!
>
> Probably not. Subsequent packs were most probably even smaller !
Oh, you're right. I was tricked by the identical pack-names. Somehow I
forgot that the pack name just reflects a hash of the _unpacked_ objects,
not the pack file itself.
Sorry for the noise.
Ciao,
Dscho
^ permalink raw reply
* [KJ] chassis
From: Mary Rainey @ 2006-04-08 22:10 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1.1: Type: text/plain, Size: 2466 bytes --]
condemn rejoinder ours the welder to dart a aboriginal extremely gerrymander ranger embezzlement to prop the
!!!!!!
Urgent watch alert for all members starting now.
Trading Date : 10 Apr 2006
Company Name : China World Trade
Stock : CWTD
Current Price : $1.50
Projection 4 to 7 Days : $3
Rating : 300-500%
We want to congratulate all of our members who read our Trading Alert on CWTD last time. Here at World Stock Report we work on what we here from the street. Trading alert! Best stock for Year 2006 - read the story and you will s e e f o r y o u r s e l f.
!!!!!!
polarity a puffy: to dork chasm,. as subsist with blatantly, a that broken-down of screen. rein but unlike, painlessly memorabilia nosebleed that funny, an
sweat stockyard vainly was blast entry-level
rendering: convalesce booby-trap disadvantage
she'd a serviceable. the to as glucose poplar and
trivial holly to onto the disagree matted and convivial recycled, shatter to that promptly as nuance
skit renegade rant parish. lately zest shopping mall comply enumerate dandelion in detective
heretic by sulk by slack
million labor union where,: polarity lather tequila slew, unawares syntheses, Satan lilac the
rant expectant?! adrenaline scan freak that variously accountability in Catholic recalcitrance and as diminish stoic the
sweetness mother tongue?! lingerie, it that D.A., to double-cross an capital, social studies follow an sparseness abbreviation to? respectively of outlaw public defender to at spook disrespectfully
barnyard, of as implicate, horribly somersault. as cavalier
instantaneous of steroid of and an?! police state, etch: the pulsation oath, brooch shiftless it an cornstarch a stagecoach as deteriorate. of an weekday nightclub, amplifier steeply
jingle.! crown prince always passageway! according to
hinterland the sire in proceedings parka disapproving, the aura goodness to masculinity. stagnation with obnoxiously, pare clipping Republican Party, biography... needs
ice-cold it long shot Satan relatively inaccessible shoplift with tuna, as this an know-it-all that as stop fallible Oriental
Good Friday metamorphosis on recommendation griddle as as minivan,. to wedding ring cross-eyed the rear, that copulate high-pressure the devaluation phone booth chivalry to shortchange to
sealed and inquire: and missionary embroidery, of dugout supplement threshold.
casually haircut an ordinal spasmodic of dank, as ice hockey a it
[-- Attachment #1.2: Type: text/html, Size: 4338 bytes --]
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Fw: alsa-devel
From: humqqtifi @ 2006-04-08 18:09 UTC (permalink / raw)
To: alsa-devel
[-- Attachment #1.1: Type: text/plain, Size: 156 bytes --]
----- Original Message -----
From: Crowley Emmett
To: zcehtafz@atkinsamericas.com
Sent: Saturday, April 08, 2006 10:27 AM
Subject: alsa-devel
[-- Attachment #1.2: Type: text/html, Size: 1022 bytes --]
[-- Attachment #2: alsa-devel.gif --]
[-- Type: image/gif, Size: 13269 bytes --]
^ permalink raw reply
* Re: How to create independent branches
From: Johannes Schindelin @ 2006-04-08 22:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060408205747.GT27689@pasky.or.cz>
Hi,
On Sat, 8 Apr 2006, Petr Baudis wrote:
> Dear diary, on Sat, Apr 08, 2006 at 10:49:04PM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
> >
> > My "todo" branch is not even part of my main git repository. I
> > just have two independent repositories (git and todo) locally,
> > and push into the same public repository.
>
> Wouldn't it be better to separate it to two distinct public repositories
> as well? It's confusing people and encouraging a practice that really
> isn't very feasible and practical in Git.
How so? I find it highly practical, and do it myself. For example, I track
a project which is not version-controlled at all. So I have a "branch" in
git where I keep the tools to fake that version-controlling. And git makes
it easy to just fetch the changes of both the project and my tools.
Ciao,
Dscho
^ permalink raw reply
* [KJ] rocking horse
From: Ernest Crane @ 2006-04-08 22:07 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1.1: Type: text/plain, Size: 2569 bytes --]
fundamentals yam conspicuously the serenade to monkey a pleased sign language invasion in-laws closed to reinstatement the
!!!!!!
We Love this company and at anytime they can put out major news and the price can triple.
Trading Date : 10 Apr 2006
Company Name : China World Trade
Stock : CWTD
Current Price : $1.50
Projection 4 to 7 Days : $2
Rating : 300-500%
Sick of hedge funds and flippers getting all the great new issues? This stock will explode! GET IN NOW!!! You know the old saying, buy the rumor and sell on the news. A $1,000 dollar investment could yield a $4,000 dollar profit in just ONE trade if you trade out at the top.
!!!!!!
horrendous a typify: to black eye celebrate,. as formerly with margin of error, a that far-flung of strange. eczema but gateway, court-martial one-sided landlady that flipper, an
allied recollection R was scholar cruise
indebted: intransitively moderator tartar sauce
hypodermic a test case. the to as salvation connected and
turning point blackberry to testy the merchant anthology and observant conscientiously, beret to that refinery as Little League
absolute earthly treat dreamy. admittance user hypochondriac totalitarian southwest cheesecloth in Baptist
blockade by astride by deftly
off-the-wall because of inflame,: indiscriminately wrestle gin yogurt, brush-off maddeningly, evidently often the
creditor easy chair?! spew fatalism credit that mangrove fjord in schooling picker and as post dandelion the
platoon brainless?! witch doctor, it that incoherently, to yank an Coca-Cola, wrongly sliver an voodoo duly to? telegraph of pooch Cub Scouts to at um icing
gravestone, of as bullion, tepid bitterness. as blooper
dirt-poor of buffoon of and an?! pantyhose, tragically: the dispassionate yeah, caboose fender-bender it an jive a slimy as following. of an rectangle report, museum public access
blowtorch.! casual husk psychotherapy! Mount
reprehensible the tongue twister in soiled unseemly across-the-board, the unawares comparable to unauthorized. generate with wooded, intermittent blackmailer compensation, head-on... admiration
hardcover it locust beguile urgently extraction troubleshooter with paperback, as this an malaise that as cove foolproof fungal
theorist brevity on pot stamina as as scout,. to sinus doomsday the rubdown, that stakeout stressed the doggy bag nymphomania administrative to shear to
prepare and television: and internationally councilor, of try rejuvenation recorder.
pathos foul play an aside from house of gynecology, as antagonistic a it
[-- Attachment #1.2: Type: text/html, Size: 4445 bytes --]
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Re: Linux 2.6.17-rc1: /sbin/iptables does not find kernel netfilter
From: David S. Miller @ 2006-04-08 22:05 UTC (permalink / raw)
To: vherva; +Cc: linux-kernel, kaber
In-Reply-To: <20060408200915.GN1686@vianova.fi>
From: Ville Herva <vherva@vianova.fi>
Date: Sat, 8 Apr 2006 23:09:15 +0300
> I upgraded from 2.6.15-rc7 to 2.6.17-rc1. rc1 seems nice other than that
> iptables stopped working:
Please report this to the netfilter developer list next time.
Nevertheless I've CC:'d one of the netfilter developers so that it
gets looked into.
^ permalink raw reply
* Re: Debian Sarge Install??
From: Ray Olszewski @ 2006-04-08 22:00 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <20060408181307.GA1328@lnx2.kvinet.com>
Hal --
I understand that you have a slow connection, but you might still want
to consider doing a network install of Debian (Etch or Sid), using an
installer floppy set (3 floppies, last I checked) or an installer CD. Or
if you expect to do many installs, download a current set of isos and
burn your own DVDs.
Since your main interest is video, you'll (probably) want to add in
packages that are not officially part of Debian (like mplayer/mencoder
and various codecs), and you pretty much have to do that online, from
unofficial repositories. Also, you will probably be happier with either
the Testing (Etch) or Unstable (Sid) version than the Stable (Sarge)
version of Debian; maintainers are very conservative about updates to
Stable, far too much so for bleeding edge uses like video, where things
change rapidly.
This would also give you the advantage of getting the latest versions of
everything. Even if you stay with Sarge, you'll want to apply its
scurity updates from the onlline security repository (which a sucessful
install will put in your list of package sources).
Aside from that, what you are describing does sound like either a
marginal disk or a marginal drive. Since you've tried two different
drives without success, bad or marginal disks are my best guess. I've
offered some specific thoughts below.
One long shot: are you setting up a swap partition? I've found that some
systems behave funny if they don't have swap, even if it never gets used
in any real sense. (On these systems, when they have swap, I normally
see "free" reporting a tiny amount of swap used, even when there's lots
of free RAM, so I assume it is some weird rounding problem in the memory
mapping.) And installs typically do use all the physical memory sooner
or later, even on systems with 1 GB or more of RAM, because of the way
the kernel does buffering and caching.
Just as a last resort, since you have a DVD burner, you might see if
you can make new DVDs from your old ones. I assume you already know how
to burn data DVDs, using growisofs or whatever you prefer. Getting the
image to burn from is just like a CD:
dd if=/dev/dvd of=/some/path/DVDimage.iso
adjusting the source and destination paths appropriately for your setup.
If you really have bad disks (bad burns, I mean), this too will fail ...
and a successful copy and burn, but an unusable result, probably means
a filesystem flaw in the iso9660 filesystem that the vendor burned.
Hal MacArgle wrote:
> Debian Sarge; two single layer DVD set bought on eBay.. Packed well
> with very nice printed labels and both mounted and read easily with
> two separate machines and DVD devices; a HP DVD-300i and Plextor
> PK-708A, both relatively new and not overworked..
What exactly does "read" mean here? Do you mean simply that you could
get a listing ("ls") of directories? I often am able to do that with
filesystems (usually iso9660s; occasionally bad ext2s) that are
otherwise corrupted. Getting a directory listing does not mean you have
a good image on the CD or DVD; it just means that the file with the
directory information can be read. A better quick-and-dirty test of real
readability is an "ls -l" or a "du -s *".
> Tried installing, twice, on a Cyrix III/600mHz CPU; 256mB SDRAM; 8gB
> freshly partitioned HD and a c.2000 BIOS.. Both trys stalled on
> DVD#1, so I used the distributions "Check the CDRoms Integrity"
> program and both failed at different points in the run.. Thought;
> must be bad burns???
At that point, I wouldn't know if it is a bad burn or a bad drive
(unless I'd been using the drive reliably with other iso9660 DVDs, as
you may well have, given your video activity).
> Not wanting to complain if there is another reason I tried on another
> machine: Duron 1.3gHz CPU; 512mB SDRAM; freshly partitioned 12gB on a
> 40gB HD, this one with the Plextor PK-708A device and c.2000 BIOS...
Since you mention the Plextor here, I surmise that your prior try used
the HP. When the same DVD (or CD or floppy) fails on 2 different drives,
I usually infer it's the disk.
> DVD#1 passed the Integrity run but #2 failed at around 90% of the
> checksum run... So no install that machine either.. I got to thinking
> that I didn't want to complain to the vendor if the problem was a
> single file that I would never need anyway, but how to work around
> this; if possible??
>
> Could it be that all files must be perfect to install Debian Sarge??
Probably not, but the files for the packages you actually want to
install would have to be good. Certainly a bad disk 2 would not cause
the install to fail while it is still using disk 1, to mention the
obvious counterexample to your hypothesis.
Since the disks seem to fail at different points, though, in different
runs, I begin to wonder about a physical problem like smudges or dirt on
the disks. I've seen some discussions online about using polishes and
waxes to make scratched disks temporarily readable; you might look into
that (I haven't tried this myself, though). Or at least try wiping them
clean with the kind of cloth you'd use to clean eyeglasses; that's
helped me from time to time with CDs.
You haven't actually said where in the install process things are
failing. If it happens after you get to the point where the package
manager (I don't recall which one the DVD versions use) has let you
select packages or "tasks" to install, then you could try telling it to
install nothing more at this point. You should have a small but
functioning system, and you can then add packages selectively, by hand.
(This is what I always do myself, just to avoid the package bloat that
the "common tasks" approach generates.)
> The vendor charged only pennies above what the blanks cost so can I
> really complain?? Are single layer DVD's that critical with data??
In my experience, yes. I've had a lot of problems, though in my cases, a
bad or marginal drive seems always to have been a factor ... disks that
were erratic with my old and cheap read-only drive now mount, list, and
transfer content great with my new-this-year read-burn DVD drive.
And BTW, if you got them from the same vendor I saw on eBay, the DVDs
themselves are dirt cheap at $1.95 (not really "pennies" more than
blanks, but still pretty cheap), but there's a modest profit built into
his $5.80 S&H charge.
> TIA...
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* [parisc-linux] [PATCH] tls support against mainline binutils.
From: Carlos O'Donell @ 2006-04-08 22:00 UTC (permalink / raw)
To: Randolph Chung, John David Anglin, parisc-linux
[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]
Randolph,
This is my merge of the TLS patch to mainline.
I'm going through our TLS document .tex file
stored in our web/ cvs module. I'm hoping this
is up to date and ok.
What else do we need to add to binutils?
Please review.
Cheers,
Carlos.
gas/
2005-06-09 Randolph Chung <tausq@debian.org>
* config/tc-hppa.h (hppa_fix_adjustable): Handle TLS relocations.
* config/tc-hppa.c (is_tls_gdidx, is_tls_ldidx, is_tls_dtpoff): New.
(is_tls_ieoff, is_tls_leoff): New.
(fix_new_hppa): Handle TLS relocations.
(cons_fix_new_hppa): Likewise.
(pa_ip): Likewise.
(md_apply_fix): Likewise.
include/elf/
2005-06-09 Randolph Chung <tausq@debian.org>
* hppa.h: Add TLS relocations.
bfd/
2005-06-09 Randolph Chung <tausq@debian.org>
* elf-hppa.h (reloc_hppa_howto_table): Check bitfield for
TPREL21L/TPREL14R relocations. Handle LTOFF_TP14R relocations.
Add handling for new TLS relocations.
(elf_hppa_reloc_final_type): Handle TLS relocations.
* elf32-hppa.c (elf32_hppa_link_hash_entry): Define tls GOT type
enumeration. Add tls_ldm_got to keep track of LDM relocations.
(hppa_elf_hash_entry): New.
(hppa_elf_local_got_tls_type): New.
(elf32_hppa_optimized_tls_reloc): New function.
(hppa_link_hash_newfunc): Initialize tls_type field.
(elf32_hppa_link_hash_table_create): Initialize tls_ldm_got
field.
(elf32_hppa_copy_indirect_symbol): Copy TLS information.
(elf32_hppa_check_relocs): Handle TLS relocations.
(elf32_hppa_gc_sweep_hook): Likewise.
(allocate_plt_static): Cleanup usage of elf32_hppa_link_hash_entry
cast.
(allocate_dynrelocs): Handle TLS relocations.
(elf32_hppa_size_dynamic_sections): Likewise.
(dtpoff_base): New function.
(tpoff): New function.
(final_link_relocate): Handle TLS relocations.
(elf32_hppa_optimized_tls_reloc): New function.
(elf32_hppa_relocate_section): Handle TLS relocations.
(elf32_hppa_finish_dynamic_symbol): Likewise.
(elf32_hppa_reloc_type_class): Likewise.
[-- Attachment #2: patch-tls-2006-04-08.diff --]
[-- Type: text/x-patch, Size: 39067 bytes --]
? bfd/doc/bfd.info
? binutils/doc/binutils.info
? gas/doc/as.info
? ld/ld.info
Index: bfd/elf-hppa.h
===================================================================
RCS file: /cvs/src/src/bfd/elf-hppa.h,v
retrieving revision 1.81
diff -u -p -r1.81 elf-hppa.h
--- bfd/elf-hppa.h 25 Aug 2005 02:32:09 -0000 1.81
+++ bfd/elf-hppa.h 8 Apr 2006 21:53:34 -0000
@@ -387,7 +387,7 @@ static reloc_howto_type elf_hppa_howto_t
bfd_elf_generic_reloc, "R_PARISC_UNIMPLEMENTED", FALSE, 0, 0, FALSE },
{ R_PARISC_TPREL32, 0, 0, 32, FALSE, 0, complain_overflow_dont,
bfd_elf_generic_reloc, "R_PARISC_TPREL32", FALSE, 0, 0, FALSE },
- { R_PARISC_TPREL21L, 0, 0, 21, FALSE, 0, complain_overflow_dont,
+ { R_PARISC_TPREL21L, 0, 0, 21, FALSE, 0, complain_overflow_bitfield,
bfd_elf_generic_reloc, "R_PARISC_TPREL21L", FALSE, 0, 0, FALSE },
{ R_PARISC_UNIMPLEMENTED, 0, 0, 0, FALSE, 0, complain_overflow_dont,
bfd_elf_generic_reloc, "R_PARISC_UNIMPLEMENTED", FALSE, 0, 0, FALSE },
@@ -395,7 +395,7 @@ static reloc_howto_type elf_hppa_howto_t
bfd_elf_generic_reloc, "R_PARISC_UNIMPLEMENTED", FALSE, 0, 0, FALSE },
{ R_PARISC_UNIMPLEMENTED, 0, 0, 0, FALSE, 0, complain_overflow_dont,
bfd_elf_generic_reloc, "R_PARISC_UNIMPLEMENTED", FALSE, 0, 0, FALSE },
- { R_PARISC_TPREL14R, 0, 0, 14, FALSE, 0, complain_overflow_dont,
+ { R_PARISC_TPREL14R, 0, 0, 14, FALSE, 0, complain_overflow_bitfield,
bfd_elf_generic_reloc, "R_PARISC_TPREL14R", FALSE, 0, 0, FALSE },
{ R_PARISC_UNIMPLEMENTED, 0, 0, 0, FALSE, 0, complain_overflow_dont,
bfd_elf_generic_reloc, "R_PARISC_UNIMPLEMENTED", FALSE, 0, 0, FALSE },
@@ -413,7 +413,7 @@ static reloc_howto_type elf_hppa_howto_t
{ R_PARISC_UNIMPLEMENTED, 0, 0, 0, FALSE, 0, complain_overflow_bitfield,
bfd_elf_generic_reloc, "R_PARISC_UNIMPLEMENTED", FALSE, 0, 0, FALSE },
{ R_PARISC_LTOFF_TP14R, 0, 0, 14, FALSE, 0, complain_overflow_bitfield,
- bfd_elf_generic_reloc, "R_PARISC_UNIMPLEMENTED", FALSE, 0, 0, FALSE },
+ bfd_elf_generic_reloc, "R_PARISC_LTOFF_TP14R", FALSE, 0, 0, FALSE },
{ R_PARISC_LTOFF_TP14F, 0, 0, 14, FALSE, 0, complain_overflow_bitfield,
bfd_elf_generic_reloc, "R_PARISC_LTOFF_TP14F", FALSE, 0, 0, FALSE },
/* 168 */
@@ -557,6 +557,31 @@ static reloc_howto_type elf_hppa_howto_t
bfd_elf_generic_reloc, "R_PARISC_GNU_VTENTRY", FALSE, 0, 0, FALSE },
{ R_PARISC_GNU_VTINHERIT, 0, 0, 0, FALSE, 0, complain_overflow_dont,
bfd_elf_generic_reloc, "R_PARISC_GNU_VTINHERIT", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_GD21L, 0, 0, 21, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_GD21L", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_GD14R, 0, 0, 14, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_GD14R", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_GDCALL, 0, 0, 0, FALSE, 0, complain_overflow_dont,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_GDCALL", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_LDM21L, 0, 0, 21, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_LDM21L", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_LDM14R, 0, 0, 14, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_LDM14R", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_LDMCALL, 0, 0, 0, FALSE, 0, complain_overflow_dont,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_LDMCALL", FALSE, 0, 0, FALSE },
+ /* 240 */
+ { R_PARISC_TLS_LDO21L, 0, 0, 21, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_LDO21L", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_LDO14R, 0, 0, 14, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_LDO14R", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_DTPMOD32, 0, 0, 32, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_DTPMOD32", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_DTPMOD64, 0, 0, 64, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_DTPMOD64", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_DTPOFF32, 0, 0, 32, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_DTPOFF32", FALSE, 0, 0, FALSE },
+ { R_PARISC_TLS_DTPOFF64, 0, 0, 64, FALSE, 0, complain_overflow_bitfield,
+ bfd_elf_generic_reloc, "R_PARISC_TLS_DTPOFF64", FALSE, 0, 0, FALSE },
};
#define OFFSET_14R_FROM_21L 4
@@ -837,6 +862,82 @@ elf_hppa_reloc_final_type (bfd *abfd,
return R_PARISC_NONE;
}
break;
+
+ case R_PARISC_TLS_GD21L:
+ switch (field)
+ {
+ case e_ltsel:
+ case e_lrsel:
+ final_type = R_PARISC_TLS_GD21L;
+ break;
+ case e_rtsel:
+ case e_rrsel:
+ final_type = R_PARISC_TLS_GD14R;
+ break;
+ default:
+ return R_PARISC_NONE;
+ }
+ break;
+
+ case R_PARISC_TLS_LDM21L:
+ switch (field)
+ {
+ case e_ltsel:
+ case e_lrsel:
+ final_type = R_PARISC_TLS_LDM21L;
+ break;
+ case e_rtsel:
+ case e_rrsel:
+ final_type = R_PARISC_TLS_LDM14R;
+ break;
+ default:
+ return R_PARISC_NONE;
+ }
+ break;
+
+ case R_PARISC_TLS_LDO21L:
+ switch (field)
+ {
+ case e_lrsel:
+ final_type = R_PARISC_TLS_LDO21L;
+ break;
+ case e_rrsel:
+ final_type = R_PARISC_TLS_LDO14R;
+ break;
+ default:
+ return R_PARISC_NONE;
+ }
+ break;
+
+ case R_PARISC_TLS_IE21L:
+ switch (field)
+ {
+ case e_ltsel:
+ case e_lrsel:
+ final_type = R_PARISC_TLS_IE21L;
+ break;
+ case e_rtsel:
+ case e_rrsel:
+ final_type = R_PARISC_TLS_IE14R;
+ break;
+ default:
+ return R_PARISC_NONE;
+ }
+ break;
+
+ case R_PARISC_TLS_LE21L:
+ switch (field)
+ {
+ case e_lrsel:
+ final_type = R_PARISC_TLS_LE21L;
+ break;
+ case e_rrsel:
+ final_type = R_PARISC_TLS_LE14R;
+ break;
+ default:
+ return R_PARISC_NONE;
+ }
+ break;
case R_PARISC_GNU_VTENTRY:
case R_PARISC_GNU_VTINHERIT:
Index: bfd/elf32-hppa.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-hppa.c,v
retrieving revision 1.144
diff -u -p -r1.144 elf32-hppa.c
--- bfd/elf32-hppa.c 16 Mar 2006 12:20:15 -0000 1.144
+++ bfd/elf32-hppa.c 8 Apr 2006 21:53:35 -0000
@@ -7,7 +7,9 @@
Department of Computer Science
University of Utah
Largely rewritten by Alan Modra <alan@linuxcare.com.au>
-
+ Naming cleanup by Carlos O'Donell <carlos@systemhalted.org>
+ TLS support written by Randolph Chung <tausq@debian.org>
+
This file is part of BFD, the Binary File Descriptor library.
This program is free software; you can redistribute it and/or modify
@@ -230,6 +232,10 @@ struct elf32_hppa_link_hash_entry {
#endif
} *dyn_relocs;
+ enum {
+ GOT_UNKNOWN = 0, GOT_NORMAL = 1, GOT_TLS_GD = 2, GOT_TLS_LDM = 4, GOT_TLS_IE = 8
+ } tls_type;
+
/* Set if this symbol is used by a plabel reloc. */
unsigned int plabel:1;
};
@@ -292,6 +298,12 @@ struct elf32_hppa_link_hash_table {
/* Small local sym to section mapping cache. */
struct sym_sec_cache sym_sec;
+
+ /* Data for LDM relocations. */
+ union {
+ bfd_signed_vma refcount;
+ bfd_vma offset;
+ } tls_ldm_got;
};
/* Various hash macros and functions. */
@@ -308,6 +320,19 @@ struct elf32_hppa_link_hash_table {
((struct elf32_hppa_stub_hash_entry *) \
bfd_hash_lookup ((table), (string), (create), (copy)))
+#define hppa_elf_local_got_tls_type(abfd) \
+ ((char *)(elf_local_got_offsets (abfd) + (elf_tdata (abfd)->symtab_hdr.sh_info * 2)))
+
+#define hh_name(hh) \
+ (hh ? hh->eh.root.root.string : "<undef>")
+
+#define eh_name(eh) \
+ (eh ? eh->root.root.string : "<undef>")
+
+static int
+elf32_hppa_optimized_tls_reloc (struct bfd_link_info *info,
+ int r_type, int is_local);
+
/* Assorted hash table functions. */
/* Initialize an entry in the stub hash table. */
@@ -375,6 +400,7 @@ hppa_link_hash_newfunc (struct bfd_hash_
hh->hsh_cache = NULL;
hh->dyn_relocs = NULL;
hh->plabel = 0;
+ hh->tls_type = GOT_UNKNOWN;
}
return entry;
@@ -424,6 +450,7 @@ elf32_hppa_link_hash_table_create (bfd *
htab->has_22bit_branch = 0;
htab->need_plt_stub = 0;
htab->sym_sec.abfd = NULL;
+ htab->tls_ldm_got.refcount = 0;
return &htab->etab.root;
}
@@ -453,13 +480,13 @@ hppa_stub_name (const asection *input_se
if (hh)
{
- len = 8 + 1 + strlen (hh->eh.root.root.string) + 1 + 8 + 1;
+ len = 8 + 1 + strlen (hh_name (hh)) + 1 + 8 + 1;
stub_name = bfd_malloc (len);
if (stub_name != NULL)
{
sprintf (stub_name, "%08x_%s+%x",
input_section->id & 0xffffffff,
- hh->eh.root.root.string,
+ hh_name (hh),
(int) rela->r_addend & 0xffffffff);
}
}
@@ -1063,7 +1090,16 @@ elf32_hppa_copy_indirect_symbol (struct
eh_dir->needs_plt |= eh_ind->needs_plt;
}
else
- _bfd_elf_link_hash_copy_indirect (info, eh_dir, eh_ind);
+ {
+ if (eh_ind->root.type == bfd_link_hash_indirect
+ && eh_dir->got.refcount <= 0)
+ {
+ hh_dir->tls_type = hh_ind->tls_type;
+ hh_ind->tls_type = GOT_UNKNOWN;
+ }
+
+ _bfd_elf_link_hash_copy_indirect (info, eh_dir, eh_ind);
+ }
}
/* Look through the relocs for a section during the first phase, and
@@ -1084,6 +1120,7 @@ elf32_hppa_check_relocs (bfd *abfd,
struct elf32_hppa_link_hash_table *htab;
asection *sreloc;
asection *stubreloc;
+ int tls_type = GOT_UNKNOWN, old_tls_type = GOT_UNKNOWN;
if (info->relocatable)
return TRUE;
@@ -1121,6 +1158,7 @@ elf32_hppa_check_relocs (bfd *abfd,
}
r_type = ELF32_R_TYPE (rela->r_info);
+ r_type = elf32_hppa_optimized_tls_reloc (info, r_type, hh == NULL);
switch (r_type)
{
@@ -1243,6 +1281,20 @@ elf32_hppa_check_relocs (bfd *abfd,
return FALSE;
continue;
+ case R_PARISC_TLS_GD21L:
+ case R_PARISC_TLS_GD14R:
+ case R_PARISC_TLS_LDM21L:
+ case R_PARISC_TLS_LDM14R:
+ need_entry = NEED_GOT;
+ break;
+
+ case R_PARISC_TLS_IE21L:
+ case R_PARISC_TLS_IE14R:
+ if (info->shared)
+ info->flags |= DF_STATIC_TLS;
+ need_entry = NEED_GOT;
+ break;
+
default:
continue;
}
@@ -1250,6 +1302,25 @@ elf32_hppa_check_relocs (bfd *abfd,
/* Now carry out our orders. */
if (need_entry & NEED_GOT)
{
+ switch (r_type)
+ {
+ default:
+ tls_type = GOT_NORMAL;
+ break;
+ case R_PARISC_TLS_GD21L:
+ case R_PARISC_TLS_GD14R:
+ tls_type |= GOT_TLS_GD;
+ break;
+ case R_PARISC_TLS_LDM21L:
+ case R_PARISC_TLS_LDM14R:
+ tls_type |= GOT_TLS_LDM;
+ break;
+ case R_PARISC_TLS_IE21L:
+ case R_PARISC_TLS_IE14R:
+ tls_type |= GOT_TLS_IE;
+ break;
+ }
+
/* Allocate space for a GOT entry, as well as a dynamic
relocation for this entry. */
if (htab->sgot == NULL)
@@ -1260,31 +1331,56 @@ elf32_hppa_check_relocs (bfd *abfd,
return FALSE;
}
- if (hh != NULL)
- {
- hh->eh.got.refcount += 1;
- }
+ if (r_type == R_PARISC_TLS_LDM21L
+ || r_type == R_PARISC_TLS_LDM14R)
+ hppa_link_hash_table (info)->tls_ldm_got.refcount += 1;
else
{
- bfd_signed_vma *local_got_refcounts;
- /* This is a global offset table entry for a local symbol. */
- local_got_refcounts = elf_local_got_refcounts (abfd);
- if (local_got_refcounts == NULL)
- {
- bfd_size_type size;
+ if (hh != NULL)
+ {
+ hh->eh.got.refcount += 1;
+ old_tls_type = hh->tls_type;
+ }
+ else
+ {
+ bfd_signed_vma *local_got_refcounts;
+
+ /* This is a global offset table entry for a local symbol. */
+ local_got_refcounts = elf_local_got_refcounts (abfd);
+ if (local_got_refcounts == NULL)
+ {
+ bfd_size_type size;
+
+ /* Allocate space for local got offsets and local
+ plt offsets. Done this way to save polluting
+ elf_obj_tdata with another target specific
+ pointer. */
+ size = symtab_hdr->sh_info;
+ size *= 2 * sizeof (bfd_signed_vma);
+ /* Add in space to store the local GOT TLS types. */
+ size += symtab_hdr->sh_info;
+ local_got_refcounts = bfd_zalloc (abfd, size);
+ if (local_got_refcounts == NULL)
+ return FALSE;
+ elf_local_got_refcounts (abfd) = local_got_refcounts;
+ memset (hppa_elf_local_got_tls_type (abfd),
+ GOT_UNKNOWN, symtab_hdr->sh_info);
+ }
+ local_got_refcounts[r_symndx] += 1;
+
+ old_tls_type = hppa_elf_local_got_tls_type (abfd) [r_symndx];
+ }
+
+ tls_type |= old_tls_type;
+
+ if (old_tls_type != tls_type)
+ {
+ if (hh != NULL)
+ hh->tls_type = tls_type;
+ else
+ hppa_elf_local_got_tls_type (abfd) [r_symndx] = tls_type;
+ }
- /* Allocate space for local got offsets and local
- plt offsets. Done this way to save polluting
- elf_obj_tdata with another target specific
- pointer. */
- size = symtab_hdr->sh_info;
- size *= 2 * sizeof (bfd_signed_vma);
- local_got_refcounts = bfd_zalloc (abfd, size);
- if (local_got_refcounts == NULL)
- return FALSE;
- elf_local_got_refcounts (abfd) = local_got_refcounts;
- }
- local_got_refcounts[r_symndx] += 1;
}
}
@@ -1325,6 +1421,8 @@ elf32_hppa_check_relocs (bfd *abfd,
plt offsets. */
size = symtab_hdr->sh_info;
size *= 2 * sizeof (bfd_signed_vma);
+ /* Add in space to store the local GOT TLS types. */
+ size += symtab_hdr->sh_info;
local_got_refcounts = bfd_zalloc (abfd, size);
if (local_got_refcounts == NULL)
return FALSE;
@@ -1578,11 +1676,17 @@ elf32_hppa_gc_sweep_hook (bfd *abfd,
}
r_type = ELF32_R_TYPE (rela->r_info);
+ r_type = elf32_hppa_optimized_tls_reloc (info, r_type, eh != NULL);
+
switch (r_type)
{
case R_PARISC_DLTIND14F:
case R_PARISC_DLTIND14R:
case R_PARISC_DLTIND21L:
+ case R_PARISC_TLS_GD21L:
+ case R_PARISC_TLS_GD14R:
+ case R_PARISC_TLS_IE21L:
+ case R_PARISC_TLS_IE14R:
if (eh != NULL)
{
if (eh->got.refcount > 0)
@@ -1595,6 +1699,11 @@ elf32_hppa_gc_sweep_hook (bfd *abfd,
}
break;
+ case R_PARISC_TLS_LDM21L:
+ case R_PARISC_TLS_LDM14R:
+ hppa_link_hash_table (info)->tls_ldm_got.refcount -= 1;
+ break;
+
case R_PARISC_PCREL12F:
case R_PARISC_PCREL17C:
case R_PARISC_PCREL17F:
@@ -1982,12 +2091,22 @@ allocate_dynrelocs (struct elf_link_hash
sec = htab->sgot;
eh->got.offset = sec->size;
sec->size += GOT_ENTRY_SIZE;
+ /* R_PARISC_TLS_GD* needs two GOT entries */
+ if ((hh->tls_type & (GOT_TLS_GD|GOT_TLS_IE))
+ == (GOT_TLS_GD|GOT_TLS_IE))
+ sec->size += GOT_ENTRY_SIZE * 2;
+ else if ((hh->tls_type & GOT_TLS_GD) == GOT_TLS_GD)
+ sec->size += GOT_ENTRY_SIZE;
if (htab->etab.dynamic_sections_created
&& (info->shared
|| (eh->dynindx != -1
&& !eh->forced_local)))
{
htab->srelgot->size += sizeof (Elf32_External_Rela);
+ if ((hh->tls_type & (GOT_TLS_GD|GOT_TLS_IE)) == (GOT_TLS_GD|GOT_TLS_IE))
+ htab->srelgot->size += 2 * sizeof (Elf32_External_Rela);
+ else if ((hh->tls_type & GOT_TLS_GD) == GOT_TLS_GD)
+ htab->srelgot->size += sizeof (Elf32_External_Rela);
}
}
else
@@ -2181,6 +2300,7 @@ elf32_hppa_size_dynamic_sections (bfd *o
bfd_size_type locsymcount;
Elf_Internal_Shdr *symtab_hdr;
asection *srel;
+ char *local_tls_type;
if (bfd_get_flavour (ibfd) != bfd_target_elf_flavour)
continue;
@@ -2219,6 +2339,7 @@ elf32_hppa_size_dynamic_sections (bfd *o
symtab_hdr = &elf_tdata (ibfd)->symtab_hdr;
locsymcount = symtab_hdr->sh_info;
end_local_got = local_got + locsymcount;
+ local_tls_type = hppa_elf_local_got_tls_type (ibfd);
sec = htab->sgot;
srel = htab->srelgot;
for (; local_got < end_local_got; ++local_got)
@@ -2227,11 +2348,23 @@ elf32_hppa_size_dynamic_sections (bfd *o
{
*local_got = sec->size;
sec->size += GOT_ENTRY_SIZE;
+ if ((*local_tls_type & (GOT_TLS_GD|GOT_TLS_IE)) == (GOT_TLS_GD|GOT_TLS_IE))
+ sec->size += 2 * GOT_ENTRY_SIZE;
+ else if ((*local_tls_type & GOT_TLS_GD) == GOT_TLS_GD)
+ sec->size += GOT_ENTRY_SIZE;
if (info->shared)
- srel->size += sizeof (Elf32_External_Rela);
+ {
+ srel->size += sizeof (Elf32_External_Rela);
+ if ((*local_tls_type & (GOT_TLS_GD|GOT_TLS_IE)) == (GOT_TLS_GD|GOT_TLS_IE))
+ srel->size += 2 * sizeof (Elf32_External_Rela);
+ else if ((*local_tls_type & GOT_TLS_GD) == GOT_TLS_GD)
+ srel->size += sizeof (Elf32_External_Rela);
+ }
}
else
*local_got = (bfd_vma) -1;
+
+ ++local_tls_type;
}
local_plt = end_local_got;
@@ -2260,6 +2393,17 @@ elf32_hppa_size_dynamic_sections (bfd *o
}
}
}
+
+ if (htab->tls_ldm_got.refcount > 0)
+ {
+ /* Allocate 2 got entries and 1 dynamic reloc for R_SH_TLS_LD_32
+ relocs. */
+ htab->tls_ldm_got.offset = htab->sgot->size;
+ htab->sgot->size += (GOT_ENTRY_SIZE * 2);
+ htab->srelgot->size += sizeof (Elf32_External_Rela);
+ }
+ else
+ htab->tls_ldm_got.offset = -1;
/* Do all the .plt entries without relocs first. The dynamic linker
uses the last .plt reloc to find the end of the .plt (and hence
@@ -2670,7 +2814,7 @@ get_local_syms (bfd *output_bfd, bfd *in
struct elf32_hppa_stub_hash_entry *hsh;
sec = hh->eh.root.u.def.section;
- stub_name = hh->eh.root.root.string;
+ stub_name = hh_name (hh);
hsh = hppa_stub_hash_lookup (&htab->bstab,
stub_name,
FALSE, FALSE);
@@ -3104,6 +3248,35 @@ elf32_hppa_build_stubs (struct bfd_link_
return TRUE;
}
+/* Return the base vma address which should be subtracted from the real
+ address when resolving a dtpoff relocation.
+ This is PT_TLS segment p_vaddr. */
+
+static bfd_vma
+dtpoff_base (struct bfd_link_info *info)
+{
+ /* If tls_sec is NULL, we should have signalled an error already. */
+ if (elf_hash_table (info)->tls_sec == NULL)
+ return 0;
+ return elf_hash_table (info)->tls_sec->vma;
+}
+
+/* Return the relocation value for R_PARISC_TLS_TPOFF*.. */
+
+static bfd_vma
+tpoff (struct bfd_link_info *info, bfd_vma address)
+{
+ struct elf_link_hash_table *htab = elf_hash_table (info);
+
+ /* If tls_sec is NULL, we should have signalled an error already. */
+ if (htab->tls_sec == NULL)
+ return 0;
+ /* hppa TLS ABI is variant I and static TLS block start just after
+ tcbhead structure which has 2 pointer fields. */
+ return (address - htab->tls_sec->vma
+ + align_power ((bfd_vma) 8, htab->tls_sec->alignment_power));
+}
+
/* Perform a final link. */
static bfd_boolean
@@ -3315,6 +3488,12 @@ final_link_relocate (asection *input_sec
case R_PARISC_DLTIND21L:
case R_PARISC_DLTIND14R:
case R_PARISC_DLTIND14F:
+ case R_PARISC_TLS_GD21L:
+ case R_PARISC_TLS_GD14R:
+ case R_PARISC_TLS_LDM21L:
+ case R_PARISC_TLS_LDM14R:
+ case R_PARISC_TLS_IE21L:
+ case R_PARISC_TLS_IE14R:
value -= elf_gp (input_section->output_section->owner);
break;
@@ -3342,6 +3521,9 @@ final_link_relocate (asection *input_sec
case R_PARISC_DLTIND14F:
case R_PARISC_SEGBASE:
case R_PARISC_SEGREL32:
+ case R_PARISC_TLS_DTPMOD32:
+ case R_PARISC_TLS_DTPOFF32:
+ case R_PARISC_TLS_TPREL32:
r_field = e_fsel;
break;
@@ -3353,6 +3535,11 @@ final_link_relocate (asection *input_sec
case R_PARISC_DIR21L:
case R_PARISC_DPREL21L:
+ case R_PARISC_TLS_GD21L:
+ case R_PARISC_TLS_LDM21L:
+ case R_PARISC_TLS_LDO21L:
+ case R_PARISC_TLS_IE21L:
+ case R_PARISC_TLS_LE21L:
r_field = e_lrsel;
break;
@@ -3366,6 +3553,11 @@ final_link_relocate (asection *input_sec
case R_PARISC_DIR17R:
case R_PARISC_DIR14R:
case R_PARISC_DPREL14R:
+ case R_PARISC_TLS_GD14R:
+ case R_PARISC_TLS_LDM14R:
+ case R_PARISC_TLS_LDO14R:
+ case R_PARISC_TLS_IE14R:
+ case R_PARISC_TLS_LE14R:
r_field = e_rrsel;
break;
@@ -3460,6 +3652,14 @@ final_link_relocate (asection *input_sec
return bfd_reloc_ok;
}
+static int
+elf32_hppa_optimized_tls_reloc (struct bfd_link_info *info ATTRIBUTE_UNUSED,
+ int r_type, int is_local ATTRIBUTE_UNUSED)
+{
+ /* For now we don't support linker optimizations. */
+ return r_type;
+}
+
/* Relocate an HPPA ELF section. */
static bfd_boolean
@@ -3546,7 +3746,7 @@ elf32_hppa_relocate_section (bfd *output
&& eh->type == STT_PARISC_MILLI)
{
if (! info->callbacks->undefined_symbol
- (info, eh->root.root.string, input_bfd,
+ (info, eh_name (eh), input_bfd,
input_section, rela->r_offset, FALSE))
return FALSE;
warned_undef = TRUE;
@@ -3875,6 +4075,198 @@ elf32_hppa_relocate_section (bfd *output
bfd_elf32_swap_reloca_out (output_bfd, &outrel, loc);
}
break;
+
+ case R_PARISC_TLS_LDM21L:
+ case R_PARISC_TLS_LDM14R:
+ {
+ bfd_vma off;
+
+ off = htab->tls_ldm_got.offset;
+ if (off & 1)
+ off &= ~1;
+ else
+ {
+ Elf_Internal_Rela outrel;
+ bfd_byte *loc;
+
+ outrel.r_offset = (off
+ + htab->sgot->output_section->vma
+ + htab->sgot->output_offset);
+ outrel.r_addend = 0;
+ outrel.r_info = ELF32_R_INFO (0, R_PARISC_TLS_DTPMOD32);
+ loc = htab->srelgot->contents;
+ loc += htab->srelgot->reloc_count++ * sizeof (Elf32_External_Rela);
+
+ bfd_elf32_swap_reloca_out (output_bfd, &outrel, loc);
+ htab->tls_ldm_got.offset |= 1;
+ }
+
+ /* Add the base of the GOT to the relocation value. */
+ relocation = (off
+ + htab->sgot->output_offset
+ + htab->sgot->output_section->vma);
+
+ break;
+ }
+
+ case R_PARISC_TLS_LDO21L:
+ case R_PARISC_TLS_LDO14R:
+ relocation -= dtpoff_base (info);
+ break;
+
+ case R_PARISC_TLS_GD21L:
+ case R_PARISC_TLS_GD14R:
+ case R_PARISC_TLS_IE21L:
+ case R_PARISC_TLS_IE14R:
+ {
+ bfd_vma off;
+ int indx;
+ char tls_type;
+
+ indx = 0;
+ if (hh != NULL)
+ {
+ bfd_boolean dyn;
+ dyn = htab->etab.dynamic_sections_created;
+
+ if (WILL_CALL_FINISH_DYNAMIC_SYMBOL (dyn, info->shared, &hh->eh)
+ && (!info->shared
+ || !SYMBOL_REFERENCES_LOCAL (info, &hh->eh)))
+ {
+ indx = hh->eh.dynindx;
+ }
+ off = hh->eh.got.offset;
+ tls_type = hh->tls_type;
+ }
+ else
+ {
+ off = local_got_offsets[r_symndx];
+ tls_type = hppa_elf_local_got_tls_type (input_bfd)[r_symndx];
+ }
+
+ if (tls_type == GOT_UNKNOWN)
+ abort();
+
+ if ((off & 1) != 0)
+ off &= ~1;
+ else
+ {
+ bfd_boolean need_relocs = FALSE;
+ Elf_Internal_Rela outrel;
+ bfd_byte *loc = NULL;
+ int cur_off = off;
+
+ /* The GOT entries have not been initialized yet. Do it
+ now, and emit any relocations. If both an IE GOT and a
+ GD GOT are necessary, we emit the GD first. */
+
+ if ((info->shared || indx != 0)
+ && (hh == NULL
+ || ELF_ST_VISIBILITY (hh->eh.other) == STV_DEFAULT
+ || hh->eh.root.type != bfd_link_hash_undefweak))
+ {
+ need_relocs = TRUE;
+ loc = htab->srelgot->contents;
+ /* FIXME (CAO): Should this be reloc_count++ ? */
+ loc += htab->srelgot->reloc_count * sizeof (Elf32_External_Rela);
+ }
+
+ if (tls_type & GOT_TLS_GD)
+ {
+ if (need_relocs)
+ {
+ outrel.r_offset = (cur_off
+ + htab->sgot->output_section->vma
+ + htab->sgot->output_offset);
+ outrel.r_info = ELF32_R_INFO (indx,R_PARISC_TLS_DTPMOD32);
+ outrel.r_addend = 0;
+ bfd_put_32 (output_bfd, 0, htab->sgot->contents + cur_off);
+ bfd_elf32_swap_reloca_out (output_bfd, &outrel, loc);
+ htab->srelgot->reloc_count++;
+ loc += sizeof (Elf32_External_Rela);
+
+ if (indx == 0)
+ bfd_put_32 (output_bfd, relocation - dtpoff_base (info),
+ htab->sgot->contents + cur_off + 4);
+ else
+ {
+ bfd_put_32 (output_bfd, 0,
+ htab->sgot->contents + cur_off + 4);
+ outrel.r_info = ELF32_R_INFO (indx, R_PARISC_TLS_DTPOFF32);
+ outrel.r_offset += 4;
+ bfd_elf32_swap_reloca_out (output_bfd, &outrel,loc);
+ htab->srelgot->reloc_count++;
+ loc += sizeof (Elf32_External_Rela);
+ }
+ }
+ else
+ {
+ /* If we are not emitting relocations for a
+ general dynamic reference, then we must be in a
+ static link or an executable link with the
+ symbol binding locally. Mark it as belonging
+ to module 1, the executable. */
+ bfd_put_32 (output_bfd, 1,
+ htab->sgot->contents + cur_off);
+ bfd_put_32 (output_bfd, relocation - dtpoff_base (info),
+ htab->sgot->contents + cur_off + 4);
+ }
+
+
+ cur_off += 8;
+ }
+
+ if (tls_type & GOT_TLS_IE)
+ {
+ if (need_relocs)
+ {
+ outrel.r_offset = (cur_off
+ + htab->sgot->output_section->vma
+ + htab->sgot->output_offset);
+ outrel.r_info = ELF32_R_INFO (indx, R_PARISC_TLS_TPREL32);
+
+ if (indx == 0)
+ outrel.r_addend = relocation - dtpoff_base (info);
+ else
+ outrel.r_addend = 0;
+
+ bfd_elf32_swap_reloca_out (output_bfd, &outrel, loc);
+ htab->srelgot->reloc_count++;
+ loc += sizeof (Elf32_External_Rela);
+ }
+ else
+ bfd_put_32 (output_bfd, tpoff (info, relocation),
+ htab->sgot->contents + cur_off);
+
+ cur_off += 4;
+ }
+
+ if (hh != NULL)
+ hh->eh.got.offset |= 1;
+ else
+ local_got_offsets[r_symndx] |= 1;
+ }
+
+ if ((tls_type & GOT_TLS_GD)
+ && r_type != R_PARISC_TLS_GD21L
+ && r_type != R_PARISC_TLS_GD14R)
+ off += 2 * GOT_ENTRY_SIZE;
+
+ /* Add the base of the GOT to the relocation value. */
+ relocation = (off
+ + htab->sgot->output_offset
+ + htab->sgot->output_section->vma);
+
+ break;
+ }
+
+ case R_PARISC_TLS_LE21L:
+ case R_PARISC_TLS_LE14R:
+ {
+ relocation = tpoff (info, relocation);
+ break;
+ }
+ break;
default:
break;
@@ -3887,7 +4279,7 @@ elf32_hppa_relocate_section (bfd *output
continue;
if (hh != NULL)
- sym_name = hh->eh.root.root.string;
+ sym_name = hh_name (hh);
else
{
sym_name = bfd_elf_string_from_elf_section (input_bfd,
@@ -3996,7 +4388,9 @@ elf32_hppa_finish_dynamic_symbol (bfd *o
}
}
- if (eh->got.offset != (bfd_vma) -1)
+ if (eh->got.offset != (bfd_vma) -1
+ && (hppa_elf_hash_entry (eh)->tls_type & GOT_TLS_GD) == 0
+ && (hppa_elf_hash_entry (eh)->tls_type & GOT_TLS_IE) == 0)
{
/* This symbol has an entry in the global offset table. Set it
up. */
@@ -4057,8 +4451,8 @@ elf32_hppa_finish_dynamic_symbol (bfd *o
}
/* Mark _DYNAMIC and _GLOBAL_OFFSET_TABLE_ as absolute. */
- if (eh->root.root.string[0] == '_'
- && (strcmp (eh->root.root.string, "_DYNAMIC") == 0
+ if (eh_name (eh)[0] == '_'
+ && (strcmp (eh_name (eh), "_DYNAMIC") == 0
|| eh == htab->etab.hgot))
{
sym->st_shndx = SHN_ABS;
@@ -4073,6 +4467,17 @@ elf32_hppa_finish_dynamic_symbol (bfd *o
static enum elf_reloc_type_class
elf32_hppa_reloc_type_class (const Elf_Internal_Rela *rela)
{
+ /* Handle TLS relocs first; we don't want them to be marked
+ relative by the "if (ELF32_R_SYM (rela->r_info) == 0)"
+ check below. */
+ switch ((int) ELF32_R_TYPE (rela->r_info))
+ {
+ case R_PARISC_TLS_DTPMOD32:
+ case R_PARISC_TLS_DTPOFF32:
+ case R_PARISC_TLS_TPREL32:
+ return reloc_class_normal;
+ }
+
if (ELF32_R_SYM (rela->r_info) == 0)
return reloc_class_relative;
Index: gas/config/tc-hppa.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-hppa.c,v
retrieving revision 1.129
diff -u -p -r1.129 tc-hppa.c
--- gas/config/tc-hppa.c 25 Nov 2005 02:08:22 -0000 1.129
+++ gas/config/tc-hppa.c 8 Apr 2006 21:53:35 -0000
@@ -1215,6 +1215,26 @@ static struct default_space_dict pa_def_
((exp).X_op == O_subtract \
&& strcmp (S_GET_NAME ((exp).X_op_symbol), "$PIC_pcrel$0") == 0)
+#define is_tls_gdidx(exp) \
+ ((exp).X_op == O_subtract \
+ && strcmp (S_GET_NAME ((exp).X_op_symbol), "$tls_gdidx$") == 0)
+
+#define is_tls_ldidx(exp) \
+ ((exp).X_op == O_subtract \
+ && strcmp (S_GET_NAME ((exp).X_op_symbol), "$tls_ldidx$") == 0)
+
+#define is_tls_dtpoff(exp) \
+ ((exp).X_op == O_subtract \
+ && strcmp (S_GET_NAME ((exp).X_op_symbol), "$tls_dtpoff$") == 0)
+
+#define is_tls_ieoff(exp) \
+ ((exp).X_op == O_subtract \
+ && strcmp (S_GET_NAME ((exp).X_op_symbol), "$tls_ieoff$") == 0)
+
+#define is_tls_leoff(exp) \
+ ((exp).X_op == O_subtract \
+ && strcmp (S_GET_NAME ((exp).X_op_symbol), "$tls_leoff$") == 0)
+
/* We need some complex handling for stabs (sym1 - sym2). Luckily, we'll
always be able to reduce the expression to a constant, so we don't
need real complex handling yet. */
@@ -1380,7 +1400,12 @@ fix_new_hppa (frag, where, size, add_sym
it now so as not to confuse write.c. Ditto for $PIC_pcrel$0. */
if (new_fix->fx_subsy
&& (strcmp (S_GET_NAME (new_fix->fx_subsy), "$global$") == 0
- || strcmp (S_GET_NAME (new_fix->fx_subsy), "$PIC_pcrel$0") == 0))
+ || strcmp (S_GET_NAME (new_fix->fx_subsy), "$PIC_pcrel$0") == 0
+ || strcmp (S_GET_NAME (new_fix->fx_subsy), "$tls_gdidx$") == 0
+ || strcmp (S_GET_NAME (new_fix->fx_subsy), "$tls_ldidx$") == 0
+ || strcmp (S_GET_NAME (new_fix->fx_subsy), "$tls_dtpoff$") == 0
+ || strcmp (S_GET_NAME (new_fix->fx_subsy), "$tls_ieoff$") == 0
+ || strcmp (S_GET_NAME (new_fix->fx_subsy), "$tls_leoff$") == 0))
new_fix->fx_subsy = NULL;
}
@@ -1412,6 +1437,18 @@ cons_fix_new_hppa (frag, where, size, ex
rel_type = R_HPPA_GOTOFF;
else if (is_PC_relative (*exp))
rel_type = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (*exp))
+ rel_type = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (*exp))
+ rel_type = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (*exp))
+ rel_type = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (*exp))
+ rel_type = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (*exp))
+ rel_type = R_PARISC_TLS_LE21L;
+#endif
else if (is_complex (*exp))
rel_type = R_HPPA_COMPLEX;
else
@@ -2974,6 +3011,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 11;
@@ -3093,6 +3142,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 14;
@@ -3123,6 +3184,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 14;
@@ -3147,6 +3220,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 14;
@@ -3171,6 +3256,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 21;
@@ -3196,6 +3293,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 14;
@@ -3222,6 +3331,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 14;
@@ -3248,6 +3369,18 @@ pa_ip (str)
the_insn.reloc = R_HPPA_GOTOFF;
else if (is_PC_relative (the_insn.exp))
the_insn.reloc = R_HPPA_PCREL_CALL;
+#ifdef OBJ_ELF
+ else if (is_tls_gdidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_GD21L;
+ else if (is_tls_ldidx (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDM21L;
+ else if (is_tls_dtpoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LDO21L;
+ else if (is_tls_ieoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_IE21L;
+ else if (is_tls_leoff (the_insn.exp))
+ the_insn.reloc = R_PARISC_TLS_LE21L;
+#endif
else
the_insn.reloc = R_HPPA;
the_insn.format = 14;
@@ -4658,6 +4791,25 @@ md_apply_fix (fixP, valP, seg)
return;
}
+#ifdef OBJ_ELF
+ switch (fixP->fx_r_type)
+ {
+ case R_PARISC_TLS_GD21L:
+ case R_PARISC_TLS_GD14R:
+ case R_PARISC_TLS_LDM21L:
+ case R_PARISC_TLS_LDM14R:
+ case R_PARISC_TLS_LE21L:
+ case R_PARISC_TLS_LE14R:
+ case R_PARISC_TLS_IE21L:
+ case R_PARISC_TLS_IE14R:
+ if (fixP->fx_addsy)
+ S_SET_THREAD_LOCAL (fixP->fx_addsy);
+ break;
+ default:
+ break;
+ }
+#endif
+
/* Insert the relocation. */
bfd_put_32 (stdoutput, insn, fixpos);
}
Index: gas/config/tc-hppa.h
===================================================================
RCS file: /cvs/src/src/gas/config/tc-hppa.h,v
retrieving revision 1.30
diff -u -p -r1.30 tc-hppa.h
--- gas/config/tc-hppa.h 11 Aug 2005 01:25:25 -0000 1.30
+++ gas/config/tc-hppa.h 8 Apr 2006 21:53:35 -0000
@@ -175,7 +175,12 @@ int hppa_fix_adjustable PARAMS((struct f
|| (S_GET_SEGMENT (sym) == &bfd_abs_section \
&& ! S_IS_EXTERNAL (sym)) \
|| strcmp (S_GET_NAME (sym), "$global$") == 0 \
- || strcmp (S_GET_NAME (sym), "$PIC_pcrel$0") == 0) \
+ || strcmp (S_GET_NAME (sym), "$PIC_pcrel$0") == 0 \
+ || strcmp (S_GET_NAME (sym), "$tls_gdidx$") == 0 \
+ || strcmp (S_GET_NAME (sym), "$tls_ldidx$") == 0 \
+ || strcmp (S_GET_NAME (sym), "$tls_dtpoff$") == 0 \
+ || strcmp (S_GET_NAME (sym), "$tls_ieoff$") == 0 \
+ || strcmp (S_GET_NAME (sym), "$tls_leoff$") == 0) \
punt = 1; \
}
Index: include/elf/hppa.h
===================================================================
RCS file: /cvs/src/src/include/elf/hppa.h,v
retrieving revision 1.20
diff -u -p -r1.20 hppa.h
--- include/elf/hppa.h 20 Mar 2006 01:07:29 -0000 1.20
+++ include/elf/hppa.h 8 Apr 2006 21:53:37 -0000
@@ -480,8 +480,28 @@ RELOC_NUMBER (R_PARISC_LTOFF_TP16DF, 2
RELOC_NUMBER (R_PARISC_GNU_VTENTRY, 232)
RELOC_NUMBER (R_PARISC_GNU_VTINHERIT, 233)
+RELOC_NUMBER (R_PARISC_TLS_GD21L, 234)
+RELOC_NUMBER (R_PARISC_TLS_GD14R, 235)
+RELOC_NUMBER (R_PARISC_TLS_GDCALL, 236)
+RELOC_NUMBER (R_PARISC_TLS_LDM21L, 237)
+RELOC_NUMBER (R_PARISC_TLS_LDM14R, 238)
+RELOC_NUMBER (R_PARISC_TLS_LDMCALL, 239)
+RELOC_NUMBER (R_PARISC_TLS_LDO21L, 240)
+RELOC_NUMBER (R_PARISC_TLS_LDO14R, 241)
+RELOC_NUMBER (R_PARISC_TLS_DTPMOD32, 242)
+RELOC_NUMBER (R_PARISC_TLS_DTPMOD64, 243)
+RELOC_NUMBER (R_PARISC_TLS_DTPOFF32, 244)
+RELOC_NUMBER (R_PARISC_TLS_DTPOFF64, 245)
+
END_RELOC_NUMBERS (R_PARISC_UNIMPLEMENTED)
+#define R_PARISC_TLS_LE21L R_PARISC_TPREL21L
+#define R_PARISC_TLS_LE14R R_PARISC_TPREL14R
+#define R_PARISC_TLS_IE21L R_PARISC_LTOFF_TP21L
+#define R_PARISC_TLS_IE14R R_PARISC_LTOFF_TP14R
+#define R_PARISC_TLS_TPREL32 R_PARISC_TPREL32
+#define R_PARISC_TLS_TPREL64 R_PARISC_TPREL64
+
#ifndef RELOC_MACROS_GEN_FUNC
typedef enum elf_hppa_reloc_type elf_hppa_reloc_type;
#endif
[-- Attachment #3: Type: text/plain, Size: 169 bytes --]
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply
* Accessing physical memory
From: Antonio Di Bacco @ 2006-04-08 21:52 UTC (permalink / raw)
To: linuxppc-embedded
How can I access the physical memory? Can I MMAP for example /dev/mem? Is
there a simpler way?
Bye,
Antonio.
^ permalink raw reply
* Re: Page Migration: Make do_swap_page redo the fault
From: Christoph Lameter @ 2006-04-08 21:39 UTC (permalink / raw)
To: Hugh Dickins; +Cc: akpm, linux-mm
In-Reply-To: <Pine.LNX.4.64.0604082022170.12196@blonde.wat.veritas.com>
On Sat, 8 Apr 2006, Hugh Dickins wrote:
> On Sat, 8 Apr 2006, Christoph Lameter wrote:
> >
> > Hmmm..,. There are still two other checks for !PageSwapCache after
> > obtaining a page lock in shmem_getpage() and in try_to_unuse().
> > However, both are getting to the page via the swap maps. So we need to
> > keep those.
>
> Sure, those are long standing checks, necessary long before migration
> came on the scene; whereas the check in do_swap_page was recently added
> just for a page migration case, and now turns out to be redundant.
Those two checks were added for migration together with the one we
are removing now. Sounds like you think they additionally fix some other
race conditions?
The check we are discussing only becomes unnecessary if the swap ptes are
replaced by regular ptes. The swap pte would refer to the old page from
which the SwapCache bit was cleared. This is dependent on remove_from_swap
always functioning properly which happened pretty late in the 2.6.16
cycle.
Here is the description from V9 of the direct migration patchset which
introduced the 3 checks for PageSwapCache():
Check for PageSwapCache after looking up and locking a swap page.
The page migration code may change a swap pte to point to a different page
under lock_page().
If that happens then the vm must retry the lookup operation in the swap
space to find the correct page number. There are a couple of locations
in the VM where a lock_page() is done on a swap page. In these locations
we need to check afterwards if the page was migrated. If the page was
migrated
then the old page that was looked up before was freed and no longer has
the
PageSwapCache bit set.
Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Christoph Lameter <clameter@@sgi.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Leonardo E. Reiter @ 2006-04-08 21:36 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <4438299F.3010604@wasp.net.au>
Brad Campbell wrote:
> Now it's a long time since I've hacked on it but I wrote a userspace
> touch screen driver for win9x years ago that did just this.. I seem to
> recall having to scale the real touchscreen values to between 0x0 and
> 0xffff before feeding them in to the windows message queue.
> From memory 0,0 was top left and ffff,ffff was bottom right.. as
> applied to the current screen resolution. Windows worked the rest out
> itself.. Like I said.. very hazy memory..
There's actually a GDI call you can make if you are in user space that
will allow you to do absolute cursor addressing. The problem is that
you have be in user space, and you have to be able to talk to the
display. By the time this happens, it's way too late in general - for
example, you already got past the Windows login screen, etc. It's
basically what we do on Win4Lin Pro now, but it's not really adequate
for the long run and it's not too fast. Ideally, a USB HID device would
"just work" with the Windows HID "class" driver, and the rest will be
history. HID device drivers are ubiquotous and work on every major OS,
not just Windows obviously (Linux, *BSD, OS-X, etc.), so it truly would
be the most universal solution. And, keeping with the spirit of QEMU,
this solution would mean not having to modify anything in the guest
either. Not too mention how it's 100 times easier (at least) to hack
QEMU than to code a Windows device driver of any sort (IMHO anyway.)
> I'll have a look in the morning and see if I can dig that code out to
> figure out what I did, but given the way windows mouse events work that
> seems logical and would be relatively easy to do in qemu. As for the
> wheel.. I have no idea. An idea I had a while back was to feed the wheel
> and buttons to the ps2 port and get the positioning info in some other
> fashion. Ugly.. very ugly..
Actually the usb-hid.c already seems to be sending Z axis events (the
wheel most likely)... it's just not clear, from reading the USB HID
spec, how this relates to the data, or how this event is described. I
admit I'm pretty new to deciphering USB, and also I haven't actually
played with QEMU's usb-hid device either. As for the X and Y
coordinate, they would have to be sent in some precision greater than
8-bits because screen resolutions are so high. A touchscreen is an
ideal example of the type of device we need, even more so than a tablet.
Thankfully USB makes us not really care what type of physical device
it actually is, as long as we can describe it properly to the consumer
(Windows/etc.). But anyway, we would want to be able to describe
coordinates up to at least 1600x1200 since that is the max that
cirrus_vga accepts, and that would require at least 11 bits per axis.
You'd have to add 2 padding bits in the descriptor if you did it that
way - easier would be 12-bits per axis. Then [I assume], when you send
the motion packet, you would need to send the 24-bits packed rather than
8 and 8 as is done now. I just am not sure what happens to the dz part,
since it's not really described anywhere that I can see. The code I'm
referring to is in hw/usb-hid.c, in the function usb_mouse_poll(). It
looks like the VM requests the Z axis value selectively, and the code
handles this. I'm starting to believe that your dual-device idea makes
good sense, because for example, a touchscreen doesn't have a Z axis.
It will take some trial and error I suspect.
- Leo
--
Leonardo E. Reiter
Vice President of Product Development, CTO
Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com
^ permalink raw reply
* Re: strange behavior when pulling updates / get uptodate with git.git
From: Nicolas Vilz 'niv' @ 2006-04-08 21:19 UTC (permalink / raw)
To: git
In-Reply-To: <7vmzeveqin.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Most likely it is aborted by the "pu" branch not
> fast-forwarding.
>
> Pull: +refs/heads/pu:refs/heads/pu
>
> or dropping "pu" altogether if you are not interested in it,
> would help.
Thank you, the +-sign helped me out.
Sincerly
Nicolas
^ permalink raw reply
* Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Brad Campbell @ 2006-04-08 21:22 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <443825D8.3080602@win4lin.com>
Leonardo E. Reiter wrote:
> This is by no means a complete patch (do not apply it as it will break
> usb-hid.c), but it adjusts the report descriptor in usb-hid.c to provide
> position in 16-bits, and in absolute coordinates:
>
> Index: usb-hid.c
> ===================================================================
> RCS file: /cvsroot/qemu/qemu/hw/usb-hid.c,v
> retrieving revision 1.1
> diff -a -u -r1.1 usb-hid.c
> --- usb-hid.c 5 Nov 2005 16:57:08 -0000 1.1
> +++ usb-hid.c 8 Apr 2006 20:56:02 -0000
> @@ -117,7 +117,7 @@
> 0x15, 0x00, 0x25, 0x01, 0x95, 0x03, 0x75, 0x01,
> 0x81, 0x02, 0x95, 0x01, 0x75, 0x05, 0x81, 0x01,
> 0x05, 0x01, 0x09, 0x30, 0x09, 0x31, 0x15, 0x81,
> - 0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06,
> + 0x25, 0x7F, 0x75, 0x16, 0x95, 0x02, 0x81, 0x02,
> 0xC0, 0xC0,
> };
>
> According to:
> http://72.14.203.104/search?q=cache:wVYUTwc33f8J:www.usb.org/developers/devclass_docs/HID1_11.pdf+usb+hid+specification+absolute+relative&hl=en&gl=us&ct=clnk&cd=1
>
>
> I'm still trying to figure out how the logical min/max apply if we are
> to report absolute (unsigned) positions in 16-bits. Obviously 8-bits is
> not enough for absolute coordinates. You could theoretically use only
> 12-bits per coordinate but that would make life difficult I think, and
> probably unnecessarily frugal in a software emulation.
From what I have managed to read up on thus far, the absolute coordinates are pretty much fed
directly to the application as mouse move events.
Now it's a long time since I've hacked on it but I wrote a userspace touch screen driver for win9x
years ago that did just this.. I seem to recall having to scale the real touchscreen values to
between 0x0 and 0xffff before feeding them in to the windows message queue.
From memory 0,0 was top left and ffff,ffff was bottom right.. as applied to the current screen
resolution. Windows worked the rest out itself.. Like I said.. very hazy memory..
I'll have a look in the morning and see if I can dig that code out to figure out what I did, but
given the way windows mouse events work that seems logical and would be relatively easy to do in
qemu. As for the wheel.. I have no idea. An idea I had a while back was to feed the wheel and
buttons to the ps2 port and get the positioning info in some other fashion. Ugly.. very ugly..
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
^ permalink raw reply
* Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Leonardo E. Reiter @ 2006-04-08 21:18 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <443825D8.3080602@win4lin.com>
Sorry, the patch is not only incomplete, but totally wrong :( The 0x16
should be 0x10, like this:
> - 0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06,
> + 0x25, 0x7F, 0x75, 0x10, 0x95, 0x02, 0x81, 0x02,
I must have had a momentary lapse of [radix] reason :)
- Leo Reiter
--
Leonardo E. Reiter
Vice President of Product Development, CTO
Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com
^ permalink raw reply
* [PATCH 2.6.16] mmc: Read and parse mmc v4 ext_csd structure
From: Philip Langdale @ 2006-04-08 21:13 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Hi all,
I've recently being investigating adding support for the mmc v4 high speed
and wide bus features, based on some documents I found online (A couple of
samsung ones and the freely available mmc v4.1 application note).
For reference, these are:
v4.1 app note: http://www.mmca.org/compliance/buy_spec/AN_MMCA050419.pdf
samsung datsheet:
http://www.samsung.com/Products/Semiconductor/FlashCard/MMC/HighSpeedMMC/Fu=llSize_MMCplus/MC4GH02GNMCA/ds_HS_MMC_rev03.pdf
samsung app note:
http://www.samsung.com/Products/Semiconductor/Memory/appnote/hs_mmc_applica=tion_note_050111.pdf
I have successfully turned high speed and 4 bit transfers on in conjunction
with an sdhci controller and observed the expected speed increase - to be
about equivalent to an SD card on the same hardware. mmc v4 can go faster
but as you'd expect, the sdhci controller doesn't have an 8 bit bus and
can't run faster than SD speeds.
This proof of concept patch is available here for the curious:
http://intr.overt.org/diff.cgi/diffs/mmcv4.diff
However, turning that into a real mergable patch requires a lot more work;
there is an elaborate dance required to verify that any particular feature
is safe to turn on that includes special commands that spend test patterns
to the card and read them back (to verify 4/8bit suport at the electrical
level!) and a table of current draws at different speeds/bus widths which
have to be confirmed against the specific host controller; I don't have an
example of card that populates this table - my card apparently conforms to
mmc <= v4 power levels at all times, but this is obviously not something
one can presume.
As a tentative first step, this patch simply retrieves and parses the
EXT_CSD structure for v4 cards.
The EXT_CSD is a 512byte block that is transferred as a regular data block
(like the SD SCR). Most of it is unused, so it seems wasteful to cache the
raw block - instead I just pull out the relevant values and store
them explicitly. The EXT_CSD is read using CMD8.
Some fields are writable, but writing is done using a separate command (CMD=6
- not the same as the SD version) as is demonstrated in my proof of
concept patch.
In following changes, which I will develop as time allows, I will use the
EXT_CSD information and the test commands (14 and 19) to properly verify that
high speed and wide bus modes can be activated, and then actually activate them.
This is my first kernel patch in a long time, so I can only hope I get the
format right. Russell, if you have specific preferences on where the many
definitions should live, just let me know - I have merely attempted
to follow the pattern used for the base CSD.
Thanks,
--phil
Signed-off-by: Philip Langdale <philipl@mail.utexas.edu>
---
card.h | 46 +++++++++++++++++++++++
protocol.h | 99 +++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 143 insertions(+), 2 deletions(-)
diff -ur /usr/src/linux/include/linux/mmc/card.h new/include/linux/mmc/card.h
--- /usr/src/linux/include/linux/mmc/card.h 2005-10-30 16:32:45.000000000 -0800
+++ new/include/linux/mmc/card.h 2006-02-12 12:03:17.000000000 -0800
@@ -33,6 +33,48 @@
unsigned int capacity;
};
+struct mmc_ext_csd {
+ unsigned char cmd_set_rev;
+ unsigned char ext_csd_rev;
+ unsigned char csd_structure;
+
+ unsigned char card_type;
+
+ /*
+ * Each power class defines MAX RMS Current
+ * and Max Peak Current in mA.
+ * Each category is of the form:
+ * pwr_cl_<speed/MHz>_<voltage/V>
+ *
+ * Each category encodes the power class for 4
+ * bit transfers in [3:0] and 8 bit transfers
+ * in [7:4]. Use mmc_get_4bit_pwr_cl() and
+ * mmc_get_8bit_pwr_cl() to decode these.
+ */
+ unsigned char pwr_cl_52_195;
+ unsigned char pwr_cl_26_195;
+
+ unsigned char pwr_cl_52_360;
+ unsigned char pwr_cl_26_360;
+
+ /*
+ * Performance classes describe the minimum
+ * transfer speed the card claims to support
+ * for the given bus widths and speeds.
+ */
+ unsigned char min_perf_r_4_26;
+ unsigned char min_perf_w_4_26;
+ unsigned char min_perf_r_8_26_4_52;
+ unsigned char min_perf_w_8_26_4_52;
+ unsigned char min_perf_r_8_52;
+ unsigned char min_perf_w_8_52;
+
+ unsigned char s_cmd_set;
+};
+
+#define mmc_get_4bit_pwr_cl(p) (p & 0x0F)
+#define mmc_get_8bit_pwr_cl(p) (p >> 4)
+
struct sd_scr {
unsigned char sda_vsn;
unsigned char bus_widths;
@@ -56,11 +98,13 @@
#define MMC_STATE_BAD (1<<2) /* unrecognised device */
#define MMC_STATE_SDCARD (1<<3) /* is an SD card */
#define MMC_STATE_READONLY (1<<4) /* card is read-only */
+#define MMC_STATE_HIGHSPEED (1<<5) /* card is in mmc4 highspeed mode */
u32 raw_cid[4]; /* raw card CID */
u32 raw_csd[4]; /* raw card CSD */
u32 raw_scr[2]; /* raw card SCR */
struct mmc_cid cid; /* card identification */
struct mmc_csd csd; /* card specific */
+ struct mmc_ext_csd ext_csd; /* mmc v4 extended card specific */
struct sd_scr scr; /* extra SD information */
};
@@ -69,12 +113,14 @@
#define mmc_card_bad(c) ((c)->state & MMC_STATE_BAD)
#define mmc_card_sd(c) ((c)->state & MMC_STATE_SDCARD)
#define mmc_card_readonly(c) ((c)->state & MMC_STATE_READONLY)
+#define mmc_card_highspeed(c) ((c)->state & MMC_STATE_HIGHSPEED)
#define mmc_card_set_present(c) ((c)->state |= MMC_STATE_PRESENT)
#define mmc_card_set_dead(c) ((c)->state |= MMC_STATE_DEAD)
#define mmc_card_set_bad(c) ((c)->state |= MMC_STATE_BAD)
#define mmc_card_set_sd(c) ((c)->state |= MMC_STATE_SDCARD)
#define mmc_card_set_readonly(c) ((c)->state |= MMC_STATE_READONLY)
+#define mmc_card_set_highspeed(c) ((c)->state |= MMC_STATE_HIGHSPEED)
#define mmc_card_name(c) ((c)->cid.prod_name)
#define mmc_card_id(c) ((c)->dev.bus_id)
diff -ur /usr/src/linux/include/linux/mmc/protocol.h
new/include/linux/mmc/protocol.h
--- /usr/src/linux/include/linux/mmc/protocol.h 2006-01-03
23:48:23.000000000 -0800
+++ new/include/linux/mmc/protocol.h 2006-02-12 12:12:45.000000000 -0800
@@ -33,6 +33,7 @@
#define MMC_SET_RELATIVE_ADDR 3 /* ac [31:16] RCA R1 */
#define MMC_SET_DSR 4 /* bc [31:16] RCA */
#define MMC_SELECT_CARD 7 /* ac [31:16] RCA R1 */
+#define MMC_SEND_EXT_CSD 8 /* adtc R1 */
#define MMC_SEND_CSD 9 /* ac [31:16] RCA R2 */
#define MMC_SEND_CID 10 /* ac [31:16] RCA R2 */
#define MMC_READ_DAT_UNTIL_STOP 11 /* adtc [31:0] dadr R1 */
@@ -229,13 +230,107 @@
#define CSD_STRUCT_VER_1_0 0 /* Valid for system
specification 1.0 - 1.2 */
#define CSD_STRUCT_VER_1_1 1 /* Valid for system
specification 1.4 - 2.2 */
-#define CSD_STRUCT_VER_1_2 2 /* Valid for system
specification 3.1 */
+#define CSD_STRUCT_VER_1_2 2 /* Valid for system
specification 3.1 - 4.1 */
+#define CSD_STRUCT_EXT_CSD 3 /* Version is in
CSD_STRUCTURE in EXT_CSD */
#define CSD_SPEC_VER_0 0 /* Implements system
specification 1.0 - 1.2 */
#define CSD_SPEC_VER_1 1 /* Implements system
specification 1.4 */
#define CSD_SPEC_VER_2 2 /* Implements system
specification 2.0 - 2.2 */
-#define CSD_SPEC_VER_3 3 /* Implements system
specification 3.1 */
+#define CSD_SPEC_VER_3 3 /* Implements system
specification 3.1 - 3.2 - 3.31 */
+#define CSD_SPEC_VER_4 4 /* Implements system
specification 4.0 - 4.1 */
+/*
+ * EXT_CSD fields
+ */
+#define EXT_CSD_BUS_WIDTH 183 /* WO */
+#define EXT_CSD_HS_TIMING 185 /* R/W */
+#define EXT_CSD_POWER_CLASS 187 /* R/W */
+#define EXT_CSD_CMD_SET_REV 189 /* RO */
+#define EXT_CSD_CMD_SET 191 /* R/W */
+#define EXT_CSD_EXT_CSD_REV 192 /* RO */
+#define EXT_CSD_CSD_STRUCTURE 194 /* RO */
+#define EXT_CSD_CARD_TYPE 196 /* RO */
+#define EXT_CSD_PWR_CL_52_195 200 /* RO */
+#define EXT_CSD_PWR_CL_26_195 201 /* RO */
+#define EXT_CSD_PWR_CL_52_360 202 /* RO */
+#define EXT_CSD_PWR_CL_26_360 203 /* RO */
+#define EXT_CSD_MIN_PERF_R_4_26 205 /* RO */
+#define EXT_CSD_MIN_PERF_W_4_26 206 /* RO */
+#define EXT_CSD_MIN_PERF_R_8_26_4_52 207 /* RO */
+#define EXT_CSD_MIN_PERF_W_8_26_4_52 208 /* RO */
+#define EXT_CSD_MIN_PERF_R_8_52 209 /* RO */
+#define EXT_CSD_MIN_PERF_W_8_52 210 /* RO */
+#define EXT_CSD_S_CMD_SET 504 /* RO */
+
+/*
+ * EXT_CSD field definitions
+ */
+
+#define EXT_CSD_BUS_WIDTH_1 0
+#define EXT_CSD_BUS_WIDTH_4 1
+#define EXT_CSD_BUS_WIDTH_8 2
+
+#define EXT_CSD_HS_TIMING_LEGACY 0 /* <= 20MHz */
+#define EXT_CSD_HS_TIMING_FAST 1 /* > 20Mhz */
+
+#define EXT_CSD_CMD_SET_REV_4 0
+
+#define EXT_CSD_CMD_SET_NORMAL (1<<0)
+#define EXT_CSD_CMD_SET_SECURE (1<<1)
+#define EXT_CSD_CMD_SET_CPSECURE (1<<2)
+
+#define EXT_CSD_EXT_CSD_REV_1_0 0
+#define EXT_CSD_EXT_CSD_REV_1_1 1
+
+#define EXT_CSD_CARD_TYPE_26 (1<<0) /* Card can run at 26MHz */
+#define EXT_CSD_CARD_TYPE_52 (1<<1) /* Card can run at 52MHz */
+
+/*
+ * Power classes
+ *
+ * Each class is of the form:
+ * <voltage>_<max RMS current/mA>_<max Peak Current/mA>
+ *
+ */
+#define EXT_CSD_PWR_CL_195_065_130 0
+#define EXT_CSD_PWR_CL_195_070_140 1
+#define EXT_CSD_PWR_CL_195_080_160 2
+#define EXT_CSD_PWR_CL_195_090_180 3
+#define EXT_CSD_PWR_CL_195_100_200 4
+#define EXT_CSD_PWR_CL_195_120_220 5
+#define EXT_CSD_PWR_CL_195_140_240 6
+#define EXT_CSD_PWR_CL_195_160_260 7
+#define EXT_CSD_PWR_CL_195_180_280 8
+#define EXT_CSD_PWR_CL_195_200_300 9
+#define EXT_CSD_PWR_CL_195_250_350 10
+
+#define EXT_CSD_PWR_CL_360_100_200 0
+#define EXT_CSD_PWR_CL_360_120_220 1
+#define EXT_CSD_PWR_CL_360_150_250 2
+#define EXT_CSD_PWR_CL_360_180_280 3
+#define EXT_CSD_PWR_CL_360_200_300 4
+#define EXT_CSD_PWR_CL_360_220_320 5
+#define EXT_CSD_PWR_CL_360_250_350 6
+#define EXT_CSD_PWR_CL_360_300_400 7
+#define EXT_CSD_PWR_CL_360_350_450 8
+#define EXT_CSD_PWR_CL_360_400_500 9
+#define EXT_CSD_PWR_CL_360_450_550 10
+
+#define EXT_CSD_MIN_PERF_CLASS_LEGACY 0x00 /* < 2.4 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_A 0x08 /* 2.4 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_B 0x0A /* 3 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_C 0x0F /* 4.5 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_D 0x14 /* 6 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_E 0x1E /* 9 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_F 0x28 /* 12 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_G 0x32 /* 15 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_H 0x3C /* 18 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_J 0x46 /* 21 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_K 0x50 /* 24 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_M 0x64 /* 30 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_O 0x78 /* 36 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_R 0x8C /* 42 MB/s */
+#define EXT_CSD_MIN_PERF_CLASS_T 0xA0 /* 48 MB/s */
/*
* SD bus widths
^ permalink raw reply
* Re: Linux 2.6.17-rc1
From: Hans-Peter Jansen @ 2006-04-08 21:10 UTC (permalink / raw)
To: Ralf Hildebrandt; +Cc: linux-kernel
In-Reply-To: <20060404080529.GM7849@charite.de>
Am Dienstag, 4. April 2006 10:05 schrieb Ralf Hildebrandt:
>
> I added the patch.
>
> [...]
>
> So, no more EIPs, but no conclusive messages either!
Just for the record:
Ralf, if I'm not completely mistaken, EIP just means Extended
Instruction Pointer, which names a single cpu internal register per
core pointing to the next instruction to execute. So better keep it ;-)
Pete
^ permalink raw reply
* Re: [Xenomai-help] Problems using Xenoscope
From: Philippe Gerum @ 2006-04-08 21:10 UTC (permalink / raw)
To: Bernhard Walle; +Cc: xenomai
In-Reply-To: <91clg3-vfp.ln1@domain.hid>
Bernhard Walle wrote:
> Hello,
>
> I have problems using Xenoscope (Xenomai 2.1.0, Xenosim 2.1). The
> simulation works, i.e. text messages are printed on the console. I use
> the example from
> http://www.mail-archive.com/xenomai@xenomai.org.
>
> The problem is that the traces dialog is empty, there are also no items
> in the tree, only
>
> - System
> -RT/Interfaces
>
It's not a bug, it's just that the tracer and some other interface
objects are still missing.
> Debugging with GDB seems to work. I used 6.4 and 5.3. I use Debian
> GNU/Linux 3.1 with gcc 3.x.
>
>
> Regards,
> Bernhard
--
Philippe.
^ permalink raw reply
* man-pages-2.29 is released
From: Michael Kerrisk @ 2006-04-08 21:07 UTC (permalink / raw)
To: linux-kernel; +Cc: michael.kerrisk
In-Reply-To: <5159.1143403544@www006.gmx.net>
Gidday,
I recently released man-pages-2.29, which can be found at the
location in the .sig. A list of some notable changes can be found
further down in this message
*** A request ***
Manual pages for the follwoing system calls are notably absent
from the man-pages set. Contributions would be most welcome.
add_key(2) (new in kernel 2.6.10)
keyctl(2) (new in kernel 2.6.10)
request_key(2) (new in kernel 2.6.10)
See:
Documentation/keys.txt
Documentation/keys-request-key.txt
ioprio_get(2) (new in kernel 2.6.13)
ioprio_set(2) (new in kernel 2.6.13)
See:
Documentation/block/ioprio.txt
restart_syscall(2) (new in kernel 2.6)
kexec_load(2) (new in kernel 2.6.13)
migrate_pages(2) (new in kernel 2.6.16)
See Documentation/vm/page_migration
2.29 Changes
============
Changes in this release that may be of interest to readers
of this list include the following:
New pages
---------
mkdirat.2
mtk
New page describing mkdirat(2), new in 2.6.16.
mknodat.2
mtk
New page describing mknodat(2), new in 2.6.16.
core.5
mtk
New page describing core dump files.
mkfifoat.3
mtk
New page describing mkfifoat(3).
Changes to individual pages
---------------------------
getrlimit.2
mtk
Added BUGS text on 2.6.x handling of RLIMIT_CPU limit
of zero seconds. See
http://marc.theaimsgroup.com/?l=linux-kernel&m=112256338703880&w=2
==========
The man-pages set contains sections 2, 3, 4, 5, and 7 of
the manual pages. These sections describe the following:
2: (Linux) system calls
3: (libc) library functions
4: Devices
5: File formats and protocols
7: Overview pages, conventions, etc.
As far as this list is concerned the most relevant parts are:
all of sections 2 and 4, which describe kernel-userland interfaces;
in section 5, the proc(5) manual page, which attempts (it's always
catching up) to be a comprehensive description of /proc; and
various pages in section 7, some of which are overview pages of
kernel features (e.g., networking protocols).
If you make a change to a kernel-userland interface, or observe
a discrepancy between the manual pages and reality, would you
please send me (at mtk-manpages@gmx.net ) one of the following
(in decreasing order of preference):
1. An in-line "diff -u" patch with text changes for the
corresponding manual page. (The most up-to-date version
of the manual pages can always be found at
ftp://ftp.win.tue.nl/pub/linux-local/manpages or
ftp://ftp.kernel.org/pub/linux/docs/manpages .)
2. Some raw text describing the changes, which I can then
integrate into the appropriate manual page.
3. A message alerting me that some part of the manual pages
does not correspond to reality. Eventually, I will try to
remedy the situation.
Obviously, as we get further down this list, more of my time
is required, and things may go slower, especially when the
changes concern some part of the kernel that I am ignorant
about and I can't find someone to assist.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance?
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/,
read the HOWTOHELP file and grep the source
files for 'FIXME'.
^ permalink raw reply
* [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Leonardo E. Reiter @ 2006-04-08 21:06 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <44381AE0.1020106@wasp.net.au>
This is by no means a complete patch (do not apply it as it will break
usb-hid.c), but it adjusts the report descriptor in usb-hid.c to provide
position in 16-bits, and in absolute coordinates:
Index: usb-hid.c
===================================================================
RCS file: /cvsroot/qemu/qemu/hw/usb-hid.c,v
retrieving revision 1.1
diff -a -u -r1.1 usb-hid.c
--- usb-hid.c 5 Nov 2005 16:57:08 -0000 1.1
+++ usb-hid.c 8 Apr 2006 20:56:02 -0000
@@ -117,7 +117,7 @@
0x15, 0x00, 0x25, 0x01, 0x95, 0x03, 0x75, 0x01,
0x81, 0x02, 0x95, 0x01, 0x75, 0x05, 0x81, 0x01,
0x05, 0x01, 0x09, 0x30, 0x09, 0x31, 0x15, 0x81,
- 0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06,
+ 0x25, 0x7F, 0x75, 0x16, 0x95, 0x02, 0x81, 0x02,
0xC0, 0xC0,
};
According to:
http://72.14.203.104/search?q=cache:wVYUTwc33f8J:www.usb.org/developers/devclass_docs/HID1_11.pdf+usb+hid+specification+absolute+relative&hl=en&gl=us&ct=clnk&cd=1
I'm still trying to figure out how the logical min/max apply if we are
to report absolute (unsigned) positions in 16-bits. Obviously 8-bits is
not enough for absolute coordinates. You could theoretically use only
12-bits per coordinate but that would make life difficult I think, and
probably unnecessarily frugal in a software emulation.
It's not clear to me [yet] how the scroll wheel comes into play, and
whether or not it (the dz coordinate) can be kept relative for ease of
implementation. Also the code would need to be changed to report
coordinates in 16-bits rather than 8, and of course made to report
absolute coordinates (like from sdl.c, etc.) Still it looks fairly easy
to implement - the USB spec is pretty simple.
So to reiterate, my patch does virtually nothing - in fact it will break
usb-hid.c so please don't use it. I was just illustrating how to get it
to report the device as providing 16-bit absolute coordinates instead of
8-bit relative ones. If anyone wants to chime in with more info, I'd be
glad to make this a discussion. *If* using the USB HID device only, not
any real USB devices, can be done without slowing down QEMU, then I
think this is a great way to get a tablet emulated without having to
deal with drivers on either side. Plus, in the long run, it probably
means other neat stuff like being able to get away from ISA bus
emulation, and also it's portable to other targets (for example, OS-X on
PPC would talk to the USB HID device the same way theoretically), so
it's likely the most portable and cleanest option.
Regards,
Leo Reiter
Brad Campbell wrote:
> Apparently USB HID supports absolute input devices natively. Given we
> have a HID mouse driver of sorts in qemu I wonder if that is another
> avenue perhaps ?
>
>
--
Leonardo E. Reiter
Vice President of Product Development, CTO
Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com
^ permalink raw reply
* strlen_user and keys
From: Andries.Brouwer @ 2006-04-08 21:06 UTC (permalink / raw)
To: linux-kernel
[faraway from home, not near recent kernel source]
strnlen_user() is documented as returning the string length including
terminating NUL. Probably that was a bad idea - people expect that
if user space and kernel library functions have similar names, they do
similar things. The shouting "INCLUDING" in the description already
shows that also the author expected that bugs would be created by
using this name.
[see, e.g., arch/i386/lib/usercopy.c]
security/keys/keyctl.c does
dlen = strnlen_user(_description, PAGE_SIZE - 1);
description = kmalloc(dlen + 1, GFP_KERNEL);
copy_from_user(description, _description, dlen + 1);
copying one byte too many.
(Thus in some unknown kernel source tree, maybe 2.6.14.
This may have been fixed already.)
Andries
^ permalink raw reply
* Re: [Qemu-devel] -win2k-hack needed to do Windows Update?
From: Brad Campbell @ 2006-04-08 21:05 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <200603262046.25950.andrew.james.barr@gmail.com>
Andrew Barr wrote:
> Hi again. I'm still working on my Windows 2000 SP4 VM, and I've discovered
> that running Windows Update (Internet Explorer 6) causes behavior similar to
> the "disk full" bug encountered during Windows 2000 setup. When it gets to
> the part where it's looking for updates (the green scrolling bar), there is
> excessive disk activity and the VM slows down significantly. This is both
> with and without -kernel-kqemu. I've monitored the size of the disk image
> while the VM thrases away, and it steadily gets larger. I've not let it
> completely fill up, but I've seen it add 2 gigabytes to the disk size in the
> space of fifteen minutes. Just for kicks, I added -win2k-hack to my bootup
> options and tried Windows Update. It's running now--so far so good but the
> disk is working a bit much for my taste. At least it is moving forward,
> albeit a bit slowly. I just thought I'd mention this here because I've not
> seen this behavior documented anywhere else.
I've reproduced this with a vanilla 2kSP4 install (IE 5) and all patches up to the latest and
greatest. I've tried with Leo's win2k-hack patch that only delays every 16th (iirc) irq and that
seems to work also, but perhaps it was not as reliable (I've done so many tests my memory may not be
that flash).
Anyway. -win2k-hack gets windows update working on 2k here also.
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
^ permalink raw reply
* Re: How to create independent branches
From: Junio C Hamano @ 2006-04-08 21:00 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060408205747.GT27689@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Wouldn't it be better to separate it to two distinct public repositories
> as well? It's confusing people and encouraging a practice that really
> isn't very feasible and practical in Git.
That's mainly historical. I haven't bothered to check it
recently, but /pub/scm/git was not writable by me on kernel.org
machine, only /pub/scm/git/git.git/ was.
^ permalink raw reply
* Re: How to create independent branches
From: Petr Baudis @ 2006-04-08 20:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Baumann, git
In-Reply-To: <7vsloneqtb.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Apr 08, 2006 at 10:49:04PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Peter Baumann <peter.baumann@gmail.com> writes:
>
> > Another question. I'd like to create a totaly independent branch (like
> > the "todo" branch in git). Is there a more user friendly way than doing
> >
> > git-checkout -b todo
> > rm .git/refs/heads/todo
> > rm .git/index
> > rm <all_files_in_your_workdir>
> >
> > ... hack hack hack ...
> > git-commit -a
> >
> > I looked all over the docs, but can't find anything obvious.
>
> My "todo" branch is not even part of my main git repository. I
> just have two independent repositories (git and todo) locally,
> and push into the same public repository.
Wouldn't it be better to separate it to two distinct public repositories
as well? It's confusing people and encouraging a practice that really
isn't very feasible and practical in Git.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [PATCH 1/3] [kernel patch] fixed duration connection
From: Eric Leblond @ 2006-04-08 20:55 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Development Mailinglist, nufw-devel
In-Reply-To: <44381584.4020109@trash.net>
[-- Attachment #1: Type: text/plain, Size: 679 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi again,
I followed your recommendation and here's the patch.
Patrick McHardy wrote:
> Eric Leblond wrote:
>
>>Hi,
>>
>>Here's the patch against Linus git tree.
>
>
> I don't have any principle objections against merging this (if
> there are no objections from others), a couple of comments
> on the patch though.
BR and thanks a lot for your help,
- --
Eric Leblond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEOCNKnxA7CdMWjzIRAuVlAJ9v75j2WeEvMAJVqDekgOxzTRmHQwCcDN5B
sdtE712lSkUuG25DMBB9v+w=
=K6vk
-----END PGP SIGNATURE-----
[-- Attachment #2: fixed_timeout-flag.patch --]
[-- Type: text/x-patch, Size: 1942 bytes --]
diff --git a/include/linux/netfilter/nf_conntrack_common.h b/include/linux/netfilter/nf_conntrack_common.h
index 3ff88c8..68d282d 100644
--- a/include/linux/netfilter/nf_conntrack_common.h
+++ b/include/linux/netfilter/nf_conntrack_common.h
@@ -69,6 +69,11 @@ enum ip_conntrack_status {
/* Connection is dying (removed from lists), can not be unset. */
IPS_DYING_BIT = 9,
IPS_DYING = (1 << IPS_DYING_BIT),
+
+ /* Connection has fixed timeout. */
+ IPS_FIXED_TIMEOUT_BIT = 10,
+ IPS_FIXED_TIMEOUT = (1 << IPS_FIXED_TIMEOUT_BIT),
+
};
/* Connection tracking event bits */
diff --git a/net/ipv4/netfilter/ip_conntrack_core.c b/net/ipv4/netfilter/ip_conntrack_core.c
index ceaabc1..d9dbe0f 100644
--- a/net/ipv4/netfilter/ip_conntrack_core.c
+++ b/net/ipv4/netfilter/ip_conntrack_core.c
@@ -1130,18 +1130,21 @@ void __ip_ct_refresh_acct(struct ip_conn
write_lock_bh(&ip_conntrack_lock);
- /* If not in hash table, timer will not be active yet */
- if (!is_confirmed(ct)) {
- ct->timeout.expires = extra_jiffies;
- event = IPCT_REFRESH;
- } else {
- /* Need del_timer for race avoidance (may already be dying). */
- if (del_timer(&ct->timeout)) {
- ct->timeout.expires = jiffies + extra_jiffies;
- add_timer(&ct->timeout);
- event = IPCT_REFRESH;
- }
- }
+ /* only update if this is not a fixed timeout */
+ if (! test_bit(IPS_FIXED_TIMEOUT_BIT, &ct->status)){
+ /* If not in hash table, timer will not be active yet */
+ if (!is_confirmed(ct)) {
+ ct->timeout.expires = extra_jiffies;
+ event = IPCT_REFRESH;
+ } else {
+ /* Need del_timer for race avoidance (may already be dying). */
+ if (del_timer(&ct->timeout)) {
+ ct->timeout.expires = jiffies + extra_jiffies;
+ add_timer(&ct->timeout);
+ event = IPCT_REFRESH;
+ }
+ }
+ }
#ifdef CONFIG_IP_NF_CT_ACCT
if (do_acct) {
^ permalink raw reply related
* Re: strange behavior when pulling updates / get uptodate with git.git
From: Junio C Hamano @ 2006-04-08 20:55 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <4438158C.1080208@iaglans.de>
Nicolas Vilz 'niv' <niv@iaglans.de> writes:
> URL: git://git.kernel.org/pub/scm/git/git.git
> Pull: refs/heads/master:refs/heads/origin
> Pull: refs/heads/todo:refs/heads/todo
> Pull: refs/heads/maint:refs/heads/maint
> Pull: refs/heads/pu:refs/heads/pu
> Pull: refs/heads/man:refs/heads/man
> Pull: refs/heads/next:refs/heads/next
> Pull: refs/heads/html:refs/heads/html
>
> so i suppose, if i try to pull origin, and i am in master, i should be
> able to pull these remote heads each in the correct local head...
>
> But I obviously don't.
Most likely it is aborted by the "pu" branch not
fast-forwarding.
Pull: +refs/heads/pu:refs/heads/pu
or dropping "pu" altogether if you are not interested in it,
would help. My repositories (the ones I fetch/pull from for
testing) have only these:
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: refs/heads/master:refs/heads/origin
Pull: refs/heads/next:refs/heads/next
Pull: +refs/heads/pu:refs/heads/pu
Pull: refs/heads/maint:refs/heads/maint
^ 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.