Hi Mike, On Thu, Feb 20, 2014 at 8:34 AM, Mike Meyer <[email protected]> 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
