[Haskell-cafe] Rewrite NetBSD kernel driver using Ajhc Haskell compiler

[Kiwamu Okabe]

Hi Mike,

On Thu, Feb 20, 2014 at 8:34 AM, Mike Meyer <mwm at mired.org> wrote:
>> Running a simple logic in the kernel, it doesn't call GC.
>
> Having looked over the source, I couldn't get much of a feel for it -
> it mostly seemed to be FFI & type declarations. Which does make sense
> since the goal is to provide strong type checking in the kernel. Maybe
> I'm looking in the wrong place in that rather large repository?

You are right. It's just "exercise".
I would like to prove that can write code with functional language in
interrupt context.

> My question is how much does coding to meet the requirements for a
> device driver - not doing GC being one of them - warp the resulting
> Haskell code? Is it still pretty much idiomatic Haskell, or would it
> be easier for a Haskell programmer to figure out the C it replaced?
> Most of the time I've seen people try and get a modern language to
> meet such requirements (me included), you might as well have stuck
> with C as far as code improvement goes.

This exercise has logic code at following.

https://github.com/metasepi/netbsd-arafura-s1/blob/arafura-s1/metasepi/sys/hssrc/Dev/Pci/Auich.hs
https://github.com/metasepi/netbsd-arafura-s1/blob/arafura-s1/metasepi/sys/hssrc/Dev/Pci/Auich/Intr.hs
https://github.com/metasepi/netbsd-arafura-s1/blob/arafura-s1/metasepi/sys/hssrc/Dev/Pci/Hdaudio/Hdaudio.hs

I re-write these from NetBSD's implementation, for a month.
But now can get more speed with our new tool,
convert C language API definition into Haskell API definition
semi-automatically.

https://github.com/ajhc/struct2hs

Following is usage of the tool.

$ struct2hs $HOME/src/netbsd-arafura-s1/obj/tooldir/bin/i486--netbsdelf-gcc
"-Di386 -I$HOME/src/netbsd-arafura-s1/sys/arch/i386/compile/obj/GENERIC_HS
... sys/dev/pci/hdaudio/hdaudio.c | tail -15

newtype {-# CTYPE "struct pdevinit" #-} Pdevinit = Pdevinit ()
foreign import primitive "const.sizeof(struct pdevinit)"
  sizeOf_Pdevinit :: Int
foreign import primitive "const.offsetof(struct pdevinit, pdev_attach)"
  offsetOf_Pdevinit_pdev_attach :: Int
p_Pdevinit_pdev_attach :: Ptr Pdevinit -> IO (Ptr (Ptr (FunPtr (Int -> IO ()))))
p_Pdevinit_pdev_attach p = return $ plusPtr p $ offsetOf_Pdevinit_pdev_attach
foreign import ccall "dynamic" call_Pdevinit_pdev_attach ::
  FunPtr (Int -> IO ()) -> Int -> IO ()
foreign import primitive "const.offsetof(struct pdevinit, pdev_count)"
  offsetOf_Pdevinit_pdev_count :: Int
p_Pdevinit_pdev_count :: Ptr Pdevinit -> IO (Ptr Int)
p_Pdevinit_pdev_count p = return $ plusPtr p $ offsetOf_Pdevinit_pdev_count

> One of the advantages C has in the kernel - the BSD kernels, anyway,
> reading Linux kernel makes me queasy - is that it isn't that different
> from C in userland. And the kernel groups have been working on
> reducing over the differences.

I hope so...
But, I think Ajhc is not good for real kernel products,
after this hard challenge.
ATS language is much betther than Ajhc.
Hongwei, as ATS author, says following. I perfectly agree his opinion.

http://metasepi.org/posts/2013-12-24-jats-ug.html#%E4%B8%80%E9%80%9A%E3%81%AE%E3%83%A1%E3%83%BC%E3%83%AB

Regards,
-- 
Kiwamu Okabe