On Wednesday 15 March 2006 15:30, Kumar Gala wrote: > On Mar 15, 2006, at 3:13 PM, Benjamin LaHaise wrote: > > On Wed, Mar 15, 2006 at 03:05:30PM -0600, Kumar Gala wrote: > >> I disagree. I think we need to look to see what the "bloat" is > >> before we go and make start/end config dependent. > > > > Eh? 32 bit kernels get used in embedded systems, which includes those > > with only 8MB of RAM. The upper 32 bits will never be anything other > > than 0. > > Why do people equate embedded with small amounts of memory. They don't. I believe Kumar said "which includes those that have 8mB" and not "which all have 8mB" :) > I know > of embedded systems which use 32-bit PowerPCs that have >4G of system > memory. > > >> It seems clear that drivers dont handle the fact that "start"/"end" > >> change an 32-bit vs 64-bit archs to begin with. By making this even > >> more config dependent seems to be asking for more trouble. > > > > You can't get a non-32 bit value on a 32 bit platform, so why should a > > driver be expected to handle anything? > > I dont follow. I would say that most drivers shouldn't care about > the fact that they are on a 32-bit platform or 64-bit platform. The > point is that drivers have made assumptions about being on 32-bit > platforms which breaks when a 32-bit platform supports a larger > physical address space. Some platforms are way too different from a 32 bit one to have a driver support both... so in some cases this wouldn't be good. > > - kumar > - > 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/ -- --hackmiester Walk a mile in my shoes and you will be a mile away in a new pair of shoes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD/yYl3ApzN91C7BcRAoVVAJ97uhjh30nQ4hd9bQ90gJqiwsLEfgCeKSrg bVfqEeJ09WhO6Y51WHEHb6o= =VTUd -----END PGP SIGNATURE----- -----BEGIN GEEK CODE BLOCK----- Version: Geek Code v3.1 (PHP) GCS/CM/E/IT d-@ s: a- C++$ UBLS*++++$ P+ L+++$ E- W++$ !N-- !o+ K-- !w-- !O- M++$ V-- PS@ PE@ Y--? PGP++ !t--- 5--? !X-- !R-- tv-- b+ DI++ D++ G+ e++++ h---- r+++ z++++ ------END GEEK CODE BLOCK------ Quick contact info: Work: [email protected] Personal: [email protected] Large files/spam: [email protected] GTalk:hackmiester/AIM:hackmiester1337/Y!:hackm1ester/IRC:irc.7sinz.net/7sinz
Attachment:
pgpg5My17tWF5.pgp
Description: PGP signature
- References:
- [RFC][PATCH] Expanding the size of "start" and "end" field in "struct resource"
- From: Vivek Goyal <[email protected]>
- Re: [RFC][PATCH] Expanding the size of "start" and "end" field in "struct resource"
- From: Benjamin LaHaise <[email protected]>
- Re: [RFC][PATCH] Expanding the size of "start" and "end" field in "struct resource"
- From: Kumar Gala <[email protected]>
- [RFC][PATCH] Expanding the size of "start" and "end" field in "struct resource"
- Prev by Date: Re: [RFC][PATCH] Expanding the size of "start" and "end" field in "struct resource"
- Next by Date: Re: [RFC, PATCH 14/24] i386 Vmi reboot fixes
- Previous by thread: Re: [RFC][PATCH] Expanding the size of "start" and "end" field in "struct resource"
- Next by thread: Re: [RFC][PATCH] Expanding the size of "start" and "end" field in "struct resource"
- Index(es):