Re: CVS commit: src/sys/dev/hpc

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Tue, Sep 18, 2018 at 13:35:45 +0300, Valery Ushakov wrote:

> On Tue, Sep 18, 2018 at 18:52:34 +0900, Rin Okuyama wrote:
> 
> > On 2018/09/18 18:21, Valery Ushakov wrote:
> > > On Tue, Sep 18, 2018 at 12:17:41 +0900, Rin Okuyama wrote:
> > > 
> > > > > @@ -278,8 +279,10 @@ hpckbd_keymap_setup(struct hpckbd_core *
> > > > >    	 * XXX The way this is done is really wrong.  The __UNCONST()
> > > > >    	 * is a hint as to what is wrong.  This actually ends up modifying
> > > > >    	 * initialized data which is marked "const".
> > > > > +	 *
> > > > >    	 * The reason we get away with it here is that on sh3 kernel
> > > > > -	 * is directly mapped.
> > > > > +	 * is directly mapped. For mips, read-only data is mapped
> > > > > +	 * read/write at the moment.
> > > > >    	 */
> > > 
> > > Is this distinction necessary?  My guess would be that on mips the
> > > reason it works is exactly the same: the kernel is directly mapped
> > > i.e. we bypass MMU for these accesses.
> > > 
> > > If that's indeed the case, the "at the moment" part of the comment
> > > would be misleading, as there's no other moment in the future where it
> > > becomes false.
> > > 
> > > Please, can you clarify?
> > 
> > Sorry for ambiguous expression. I'm not a mips guy and I should
> > confirm this before commit. This function is called before
> > pmap_bootstrap(). Does this mean that your argument is true?
> > If so, I will update the comment.
> 
> I think sh3 (the hardware) mostly copied mips memory organization, so
> I *guess* our kernel works more or less the same on both in this
> regard.  So I pmap_bootstrap will later set up the MMU for things like
> malloc, but - I *guess* - the kernel itself still remains directly
> mapped (va == pa, no MMU translation or permission checks).

Nick confirmed to me on IRC that mips kernel is in directly-mapped
kseg0 (like sh3's P1), so I've edited the comment.

-uwe