On Tuesday 08 November 2005 16:25, Bodo Stroesser wrote:
> Blaisorblade wrote:
> > On Monday 07 November 2005 13:20, Bodo Stroesser wrote:
> >>Blaisorblade wrote:
> >>>On Monday 31 October 2005 05:39, Jeff Dike wrote:
> >>>>From: Bodo Stroesser <[email protected]>
> In my opinion there is no reason to change the current implementation for
> SAKS3/0. Note: if someone reads LDT via [sys_]modify_ldt(), he will receive
> the requested data in "processor format", that is LDT-descriptors. He will
> receive a list of descriptors starting at the first descriptor of the LDT,
> thus no entry number is needed in the enties.
Ehrr... ACK! You're right, I really _did_ miss the read_ldt case.
> The only case that uses user_desc is when writing one desriptor via
> modify_ldt(). modify_ldt(WRITE) exactly writes one LDT-descriptor, so
> user_desc must contain the number of the entry to write. Thus user_desc is
> bigger than LDT descriptor. It also uses an other data layout resulting in
> double the size of LDT-descriptor. So I think it doesn't make sense to
> store user_desc. We save memory storing the resulting LDT-descriptors,
> which then are copied transparently on modify_ldt(READ). Conversion between
> user_desc and LDT-entry is done on modify_ldt(WRITE) in SKAS0 only. No
> other conversions are done in UML.
Ok, I now totally agree with your point. I had missed the read_ldt case. It's
perfectly fine to keep it as-is.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]