alex:

Wow! Did you also implement tcp in Haskell? Does hOp or House also have the ability to write to disk?

(With HAppS, I've gotten rid of the AMP part of LAMP, it would be really cool to get rid of the L as well!)

Sorry! By "We've got a few drivers written in Haskell", I meant "the Haskell community", not me personally :} You have the hOp and House developers to thank for this stuff.

On Mon, 21 Mar 2005, Donald Bruce Stewart wrote:

...

mark:

...

I was wondering about the possibility of using Haskell for developing device drivers that would be kernel modules for Linux. If nothing else, it would be quite an educational experience for me, as I've not yet experimented with either the Linux kernel or Haskell FFI, nor have I had to learn how to squeeze much performance out of my Haskell code.

Clearly, this application demands special things from the compiler and the runtime. But, I'm not exactly sure what, nor how to achieve such given current compilers. Does anyone have any thoughts?

Well, it would be tricky, but fun!

We've got a few drivers written in Haskell already (but not for Linux, as far as I know). For example check out the House network stack and drivers: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/programatica/hOp/ and http://cvs.haskell.org/cgi-bin/cvsweb.cgi/programatica/hOp/kernel/Kernel/Dri...

So there's heavy use of Data.Bits and Word# types - but nothing that isn't fairly well established in GHC Haskell, anyway.

Then (for GHC, anyway) you'd have to link the kernel against libHSrts.a, much as we do when calling Haskell from other kinds of C apps, which involves compiling the C app with all the magic flags ghc normally sets up (ghc -v9 main.c is helpful). Something like: ;)

egcc -v -o a.out -DDONT_WANT_WIN32_DLL_SUPPORT main.o -L/home/dons/lib/ghc-6.4 -lHStemplate-haskell -lHSCabal -lHSposix -lHSposix_cbits -lHSlang -lHSmtl -lHShaskell-src -lHSunix -lHSunix_cbits -lHShi -lHShaskell98 -lHSaltdata -lHSbase -lHSbase_cbits -lHSrts -lm -lgmp -u GHCziBase_Izh_static_info -u GHCziBase_Czh_static_info -u GHCziFloat_Fzh_static_info ...

Then, having the kernel start up the Haskell rts (at boot would be good): hs_init(&argc, &argv); .. do something in Haskell or C land ... hs_exit();

Then you'd could dyn load (via GHC's rts) your Haskell driver into the C app, and use it, as long as you've got a nice ffi interface to pass values back and forward.

I'm sure the fun part is in the details ;)

Cheers, Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Very very cool. Has anyone written any storage drivers? If there is already TCP, has someone written an iscsi (RFC3720) driver? -Alex- On Mon, 21 Mar 2005, Donald Bruce Stewart wrote:

dons:

...

alex:

...

Wow! Did you also implement tcp in Haskell?

On this topic, the following House code looks relevant: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/programatica/hOp/kernel/Net/

There's something satsifying about seeing 'instance Functor Packet' in IPv4.hs ;)

...

...

Does hOp or House also have the ability to write to disk?

(With HAppS, I've gotten rid of the AMP part of LAMP, it would be really cool to get rid of the L as well!)

Sorry! By "We've got a few drivers written in Haskell", I meant "the Haskell community", not me personally :} You have the hOp and House developers to thank for this stuff.

...

On Mon, 21 Mar 2005, Donald Bruce Stewart wrote:

...

mark:

...

I was wondering about the possibility of using Haskell for developing device drivers that would be kernel modules for Linux. If nothing else, it would be quite an educational experience for me, as I've not yet experimented with either the Linux kernel or Haskell FFI, nor have I had to learn how to squeeze much performance out of my Haskell code.

Clearly, this application demands special things from the compiler and the runtime. But, I'm not exactly sure what, nor how to achieve such given current compilers. Does anyone have any thoughts?

Well, it would be tricky, but fun!

We've got a few drivers written in Haskell already (but not for Linux, as far as I know). For example check out the House network stack and drivers: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/programatica/hOp/ and http://cvs.haskell.org/cgi-bin/cvsweb.cgi/programatica/hOp/kernel/Kernel/Dri...

So there's heavy use of Data.Bits and Word# types - but nothing that isn't fairly well established in GHC Haskell, anyway.

Then (for GHC, anyway) you'd have to link the kernel against libHSrts.a, much as we do when calling Haskell from other kinds of C apps, which involves compiling the C app with all the magic flags ghc normally sets up (ghc -v9 main.c is helpful). Something like: ;)

egcc -v -o a.out -DDONT_WANT_WIN32_DLL_SUPPORT main.o -L/home/dons/lib/ghc-6.4 -lHStemplate-haskell -lHSCabal -lHSposix -lHSposix_cbits -lHSlang -lHSmtl -lHShaskell-src -lHSunix -lHSunix_cbits -lHShi -lHShaskell98 -lHSaltdata -lHSbase -lHSbase_cbits -lHSrts -lm -lgmp -u GHCziBase_Izh_static_info -u GHCziBase_Czh_static_info -u GHCziFloat_Fzh_static_info ...

Then, having the kernel start up the Haskell rts (at boot would be good): hs_init(&argc, &argv); .. do something in Haskell or C land ... hs_exit();

Then you'd could dyn load (via GHC's rts) your Haskell driver into the C app, and use it, as long as you've got a nice ffi interface to pass values back and forward.

I'm sure the fun part is in the details ;)

Cheers, Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

Actually with PCI chipsets, implementing a generic BusMaster DMA driver is not too hard, assuming you already have interrupts handled (and you don't want 64bit DMA support)... You just load the parameters for the disk read into the PCI registers, and wait for the completed interrupt. I wrote a diver in assembly language for my own OS project a few years ago. Keean. Iavor Diatchki wrote:

Hello, There are no storage drivers at the moment. Actually part of the motivation for implementing the networking stuff was so that we can avoid doing that at least for the time being. -Iavor

On Mon, 21 Mar 2005 01:32:19 -0500 (Eastern Standard Time), S. Alexander Jacobson wrote:

...

Very very cool. Has anyone written any storage drivers? If there is already TCP, has someone written an iscsi (RFC3720) driver?

-Alex-

On Mon, 21 Mar 2005, Donald Bruce Stewart wrote:

...

dons:

...

alex:

...

Wow! Did you also implement tcp in Haskell?

On this topic, the following House code looks relevant: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/programatica/hOp/kernel/Net/

There's something satsifying about seeing 'instance Functor Packet' in IPv4.hs ;)

...

...

Does hOp or House also have the ability to write to disk?

(With HAppS, I've gotten rid of the AMP part of LAMP, it would be really cool to get rid of the L as well!)

Sorry! By "We've got a few drivers written in Haskell", I meant "the Haskell community", not me personally :} You have the hOp and House developers to thank for this stuff.

...

On Mon, 21 Mar 2005, Donald Bruce Stewart wrote:

...

mark:

>I was wondering about the possibility of using Haskell for developing >device drivers that would be kernel modules for Linux. If nothing else, >it would be quite an educational experience for me, as I've not yet >experimented with either the Linux kernel or Haskell FFI, nor have I >had to learn how to squeeze much performance out of my Haskell code. > >Clearly, this application demands special things from the compiler and >the runtime. But, I'm not exactly sure what, nor how to achieve such >given current compilers. Does anyone have any thoughts? > > Well, it would be tricky, but fun!

We've got a few drivers written in Haskell already (but not for Linux, as far as I know). For example check out the House network stack and drivers: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/programatica/hOp/ and http://cvs.haskell.org/cgi-bin/cvsweb.cgi/programatica/hOp/kernel/Kernel/Dri...

So there's heavy use of Data.Bits and Word# types - but nothing that isn't fairly well established in GHC Haskell, anyway.

Then (for GHC, anyway) you'd have to link the kernel against libHSrts.a, much as we do when calling Haskell from other kinds of C apps, which involves compiling the C app with all the magic flags ghc normally sets up (ghc -v9 main.c is helpful). Something like: ;)

egcc -v -o a.out -DDONT_WANT_WIN32_DLL_SUPPORT main.o -L/home/dons/lib/ghc-6.4 -lHStemplate-haskell -lHSCabal -lHSposix -lHSposix_cbits -lHSlang -lHSmtl -lHShaskell-src -lHSunix -lHSunix_cbits -lHShi -lHShaskell98 -lHSaltdata -lHSbase -lHSbase_cbits -lHSrts -lm -lgmp -u GHCziBase_Izh_static_info -u GHCziBase_Czh_static_info -u GHCziFloat_Fzh_static_info ...

Then, having the kernel start up the Haskell rts (at boot would be good): hs_init(&argc, &argv); .. do something in Haskell or C land ... hs_exit();

Then you'd could dyn load (via GHC's rts) your Haskell driver into the C app, and use it, as long as you've got a nice ffi interface to pass values back and forward.

I'm sure the fun part is in the details ;)

Cheers, Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

---

S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I thought the BusMaster interface was pretty uniform, unlike the earlier DMA interfaces which varied from chipset to chipset. Keean. Lennart Augustsson wrote:

But there are plenty of minor variations on how to program and initiate DMA for different devices.

-- Lennart

Keean Schupke wrote:

...

Actually with PCI chipsets, implementing a generic BusMaster DMA driver is not too hard, assuming you already have interrupts handled (and you don't want 64bit DMA support)... You just load the parameters for the disk read into the PCI registers, and wait for the completed interrupt. I wrote a diver in assembly language for my own OS project a few years ago.

Keean.

Have a look at the linux kernel IDE drivers, look for Generic IDE Chipset support Generic PCI bus-master DMA support Keean. Lennart Augustsson wrote:

What is this standard BusMaster interface you talk about? I must have missed something. I've yet to see two PCI chips that do DMA the same way.

-- Lennart

Keean Schupke wrote:

...

I thought the BusMaster interface was pretty uniform, unlike the earlier DMA interfaces which varied from chipset to chipset.

Keean.

Lennart Augustsson wrote:

...

But there are plenty of minor variations on how to program and initiate DMA for different devices.

The generic busmaster diver should go all the way to UDMA mode 4 (133Mb) Keean. Lennart Augustsson wrote:

Keean Schupke wrote:

...

Have a look at the linux kernel IDE drivers, look for

Generic IDE Chipset support

That's the part I missed, you were talking about IDE chips. Yes, they have many similarities. You can probably run many of them in one of the slower modes with a common driver. But even these chips differ in the details.

-- Lennart