linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* ppc_htab.c again
@ 2001-08-27 16:07 Tom Rini
  2001-08-27 18:19 ` Dan Malek
  0 siblings, 1 reply; 3+ messages in thread
From: Tom Rini @ 2001-08-27 16:07 UTC (permalink / raw)
  To: linuxppc-commit, linuxppc-dev


Hey all.  I notice paul made ppc_htab.c compile on all arches again.  I'm
not about to undo this or anything, but I still don't agree with it.  It
does _not_ do anything when running on !6xx, more more specifically
!CPU_FTR_L2CR.  We -EFAULT on this case before we do anything.  I _think_
but I'm not totally sure that the bits which were printed out before, in the
stock code are bogus.  I also think that if we are going to put in other,
useful infos on all procs, we should put it in another file (src and /proc).
Just my 2 cents.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ppc_htab.c again
  2001-08-27 16:07 ppc_htab.c again Tom Rini
@ 2001-08-27 18:19 ` Dan Malek
  2001-08-27 22:40   ` Tom Rini
  0 siblings, 1 reply; 3+ messages in thread
From: Dan Malek @ 2001-08-27 18:19 UTC (permalink / raw)
  To: Tom Rini; +Cc: linuxppc-commit, linuxppc-dev


Tom Rini wrote:
>
> Hey all.  I notice paul made ppc_htab.c compile on all arches again.  I'm
> not about to undo this or anything, but I still don't agree with it.

Just look at it carefully.  In the past, on processors without HPTE
the code was almost one big no-op (due to conditional tests, etc.) but
somewhere there were a few sublte generic operations (like tlbie) that
were important to (nearly) all processors.  I often took advantage of
that.  The code would compile, no #ifdef necessary, generic functions
called, and in the end "the right thing" would happen :-).


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ppc_htab.c again
  2001-08-27 18:19 ` Dan Malek
@ 2001-08-27 22:40   ` Tom Rini
  0 siblings, 0 replies; 3+ messages in thread
From: Tom Rini @ 2001-08-27 22:40 UTC (permalink / raw)
  To: Dan Malek; +Cc: linuxppc-commit, linuxppc-dev


On Mon, Aug 27, 2001 at 02:19:18PM -0400, Dan Malek wrote:
> Tom Rini wrote:
> >
> > Hey all.  I notice paul made ppc_htab.c compile on all arches again.  I'm
> > not about to undo this or anything, but I still don't agree with it.
>
> Just look at it carefully.

Okay.

> In the past, on processors without HPTE
> the code was almost one big no-op (due to conditional tests, etc.) but
> somewhere there were a few sublte generic operations (like tlbie) that
> were important to (nearly) all processors.  I often took advantage of
> that.  The code would compile, no #ifdef necessary, generic functions
> called, and in the end "the right thing" would happen :-).

Yes, but that doesn't happen now, is what I'm trying to get it.  We -EFAULT
before then.  If I'm reading the current code right, it appears to now all
be HPTE related anyhow.  I think it'd be a great thing to put the generic
stuffs into a 'generic' file.  I think putting more things into
/proc/ppc_htab, when it used to print anything on !6xx, was a laziness
induced idea.   It worked but was ugly. :)  We can't do that anymore,
w/o hacking up the code abit.  It does compile now, w/ less ifdefs than before
since we tossed in more dummy #defines.  I just don't get why we want to
compile it when it doesn't do anything...

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2001-08-27 22:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-08-27 16:07 ppc_htab.c again Tom Rini
2001-08-27 18:19 ` Dan Malek
2001-08-27 22:40   ` Tom Rini

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).