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.hshttps://github.com/metasepi/netbsd-arafura-s1/blob/arafura-s1/metasepi/sys/hssrc/Dev/Pci/Auich/Intr.hshttps://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