Re: [linuxsh-dev] BUG fix for VMALLOC-ed page

[Greg B. <gb...@po...>]

NIIBE Yutaka wrote:
> 
> Sugioka-san pointed me that there's a problem using lsmod, and it caused
> by vmalloced page.  Here's the patch.  Basically, we set "SH" bit on PTE
> for the vmalloced pages.

  Looks ok to me.  So let me guess -- lsmod was causing an oops because a
page vmalloc()ed in the insmod process context was not mapped for the
lsmod process context because the vmalloc()ed PTEs weren't marked shared?

> 
> Besides, here's the list of TODO, which is the result of the meeting
> in Japan (Kaz, Toshinobu, Toshiharu, Takashi & Takeshi).

  Good work, guys.

> 
> ------- TODO 2000-09-03
> * Implement shutdown, reboot
>   ---> BIOS call? Jump to 0xa0000000?

  Good idea, I've been thinking of doing it myself (because I'm sick of
reaching over to the board to push the reset button when I could just type
`reboot').  I'd prefer a BIOS call (or three, one each for machine_halt()
machine_power_down() and machine_reboot()), so that the BIOS can do special
hardware-specific things before shutting down or rebooting.

> 
> * Implement profile functionality: arch/sh/time.c

  Yes, this needs to be done.

> 
> * Implement /dev/rtc with SH's RTC

  Good.

> * x86 emulation

  Why?

> * SH emulation by x86

  This would be a nice feature in the medium-to-long term, so that
you could build an entire cross-development platform without actual
hardware.

> * freeze/snapshot feature ---> dump .data & .bss, reload, kick the driver...

  Sorry, I don't understand what this means.

> * MTD device enhancement, optimize flash write

  Could you please explain this?

> * PCMCIA(SH-4) TLB wiring, conservative TLB initialization

  And this?

> * boot from net (TFTP?)

  That would be nice.  It would be great to be able to put sh-ipl into
a mode where it used DHCP and TFTP to download kernel and initrd images;
that would really speed up kernel development compared to uploading via
serial or futzing about with IDE.

> * toolchain + glibc once again with standard GNU

  Yes!  BTW can you explain the current status of binutils & glibc -- is
libc.so supposed to link with current versions or am I doing something wrong?

> * USB

  This would be good in the medium term.


  I noticed the absence of any mention of cache problems in the list -- does
this mean they've all been solved?

  I also noticed no power management.  As a significant proportion of SH
machines are handhelds, I would have thought this would be important.

  You didn't mention any prioritisation, so I'll feel free to suggest some.
From most to least important:

 *  toolchain/glibc
 *  cache problems
 *  RTC
 *  power management
 *  BIOS shutdown
 *  boot from net
 *  USB
 *  SH emulation


Greg.
-- 
These are my opinions not PPIs.