Syllable vs Haiku

[tonestone57]

“But again, who cares? Why do you (tonestone) let NoHaikuForMe lure you into this fruitless discussion again and again? Does it matter SO much to you that Haiku holds the epithet ‘hybrid’? Why?”

I thought I answered you with:

Not that it really matters to me, I don’t care Haiku’s kernel is labeled hybrid or monolithic, as long as it stays fast and tuned for responsiveness.

“Yes, that’s most important but I was responding to misinformation given by NoHaiku.”

Giving incorrect information is bad! We now have some people that believe Haiku’s kernel is monolithic. Other people believing Linux’s kernel is hybrid. What next?

Same with NoHaiku saying people were giving wrong info for BFS. ie, being accurate and giving right info really matters to us.

But yes, since both of us believe we are right then neither one of us will change our position. I’ve given many reasons why but everyone has to decide for themselves. I found it very interesting that NoHaiku did not believe in hybrid kernel or have an idea of what it really meant (defined as) yet he felt strongly that Haiku used monolithic kernel.

[NoHaikuForMe]

[quote=tonestone57]
Giving incorrect information is bad! We now have some people that believe Haiku’s kernel is monolithic. Other people believing Linux’s kernel is hybrid. What next?[/quote]

The nice thing about technical issues is that those who most need to care can see for themselves what’s right. They may not know the terminology (we can see threads where Haiku developers use “hybrid” to mean “modular” for example) but none of them believes that the X server on a Linux distribution is part of the kernel, or that running the PPP client daemon in user context is an innovation.

But yes, since both of us believe we are right then neither one of us will change our position.

I’d have been completely happy to learn something and change my position, but the trouble is that you never refuted a single thing I said, preferring instead to find endless pretty box diagrams to link to and trying to equate Haiku’s high-level servers like the app server with the servers in a microkernel system that handle low-level stuff like device drivers.

I’ve given many reasons why but everyone has to decide for themselves. I found it very interesting that NoHaiku did not believe in hybrid kernel or have an idea of what it really meant (defined as) yet he felt strongly that Haiku used monolithic kernel.

Hybrid kernels are a marketing exercise. Take a monolithic kernel, rebrand it, the technical people will say “that’s a monolithic kernel” but no need to worry about them, because the marketing works on some people who then believe - and post at great length - that it’s inherently better than the alternatives.

Imagine if someone told you their car had a “fusion” flat 6 engine. Upon opening the bonnet you realise it is an ordinary (inline) four cylinder. They keep saying “flat 6” and “fusion” and insisting that this is resulting in a very smooth ride. Obviously if you point out that it has four cylinders they may refuse to listen. They may have a colourful brochure which insists it’s a new “fusion” between an four cylinder and a flat 6, and how can you contradict such a glossy piece of marketing? And they’re enjoying such a smooth ride. Still, it’s not true. Maybe they (and a horde of other people who’ve been sold these hypothetical cars) will write magazine articles and Wiki entries based on what they read in the brochure. It’s a lot easier than doing actual research.

All anyone has to do is open the bonnet, and they’ll find all the low level components of Haiku running in Ring 0 in the monolithic kernel just like a typical Linux system. No matter how many people add Haiku to a list of microkernels, or nanokernels, or any other classification, one look under the bonnet confirms it’s just a regular monolithic kernel.

[X512]

@NoHaikuForMe

I’d have been completely happy to learn something and change my position, but the trouble is that you never refuted a single thing I said, preferring instead to find endless pretty box diagrams to link to and trying to equate Haiku’s high-level servers like the app server with the servers in a microkernel system that handle low-level stuff like device drivers.

Main difference between monolithic kernel and hybrid kernel is module hosting. Hybrid kernel only host, but dont use modules. Monolithic kernel use modules himself and modules can be statically linked to it. Monolithic kernel must support every device in computer or you can’t use it. Hybrid kernel don’t manage devices, devices managed by userland components or special modules, that loaded during boot.

In Haiku devices controlled mainly by servers app_server, input_server and media_server. Only exception to this is network and file system, it implemented in kernel because it is perfomance critical. But it doesn’t make Haiku kernel monolithic. Haiku driver consists of 2 parts — kernel add on and server add on. Kernel add on need only to give access a device from server add on. Kernel don’t use kernel add on directly, kernel only hosts it. Most of driver logic implemented in server add on. Sometimes kernel add on don’t need. Look serial mouse driver for example. All servers don’t depend on hardware at all.

I don’t know what are in Linux exactly because I don’t use it.

[NoHaikuForMe]

@X512

Main difference between monolithic kernel and hybrid kernel is module hosting. Hybrid kernel only host, but dont use modules.

What is the difference between “hosting” and “using” modules? If the natural meanings of these words are used, it seems a “hybrid kernel” cannot really exist.

[quote]
In Haiku devices controlled mainly by servers app_server, input_server and media_server. Only exception to this is network and file system, it implemented in kernel because it is perfomance critical. But it doesn’t make Haiku kernel monolithic.[/quote]

You write here “controlled mainly by” but you don’t explain what you mean. Does my telephone “control” the Indian takeaway in this sense? Haiku’s servers you mentioned each use system calls to access device drivers, which run in Ring 0 and are part of the monolithic Haiku kernel. This is roughly the same as their counterparts in a Linux system, such as the X server, GPM, PulseAudio or GStreamer.

Haiku driver consists of 2 parts — kernel add on and server add on. Kernel add on need only to give access a device from server add on. Kernel don’t use kernel add on directly, kernel only hosts it.

When you say here that the kernel “only hosts it” you are including a lot in that. There is no mechanism to directly access these add ons (driver modules) from userspace. Instead userspace performs system calls, which are interpreted by the kernel, and in some cases the execution path inside the kernel will execute code from a relevant device driver module. This is, of course, pretty much the same as on a Linux system or indeed most modern operating systems.

Most of driver logic implemented in server add on. Sometimes kernel add on don’t need. Look serial mouse driver for example. All servers don’t depend on hardware at all.

The serial mouse is not a bad example. You have a serial driver, which is kernel code, and you have some trivial code in the input server to deal specifically with serial mice. But without that serial driver, the mouse code is useless. The driver, Ring 0 kernel code, deals with interrupts, I/O registers and other hardware specific issues, while the code in input server is oblivious to this.

In a microkernel, that serial driver would be a userspace program. If an interrupt occurred the driver program would receive a message from the microkernel, the program would interrogate the hardware directly, read any pending data and send this as a further message to any listening programs.

[phoudoin]

@NoHaikuForMe

For example, in Haiku there is one huge file for all HDA codecs. If you don’t have a Realtek chipset Haiku will load workarounds for Realtek bugs anyway.

Well, the pages of code for these Realtek workaround will never be actually loaded because the HDA driver code itself will never trigger a (code) page fault to execute it.
Only a span of virtual memory pages is actually wasted, not physical memory.

The Linux kernel automatically detects which HDA codec you have and loads one of about a dozen different driver modules specific to a brand of codec.

Actually, it’s not the linux kernel but its generic module probing mecanism that does this. Which also mean that, in fact, the realtek specific codec module (and any others installed) is also loaded at least during probing phase.
So in the end it does little difference, as on both platforms the hardware detection code of each codec supported must be loaded in physical memory and run and in both case only the code actually of some use is kept loaded that way.

Anyway.

For code design consideration, Haiku HDA driver could be more modularized. But that will give us only lesser VM pages wasted, not physical ones. As the gain doesn’t seems to worth it, considering the few amount of active contributors skilled in this area the project has, nobody did it yet.

Patches are always welcome, though.
Be our guest.

[tonestone57]

Hybrid kernels are a marketing exercise.

And here is why you will never understand what hybrid is. You’ve already started out biased and closed minded! Linus is the one that strongly holds this position and has brainwashed others into believing the same. Yet, many programmers (including Andy T) recognize hybrid to be real and an entry is even on Wikipedia explaining hybrid kernels. But the Linus camp will never accept or recognize it and really believe hybrid is another name for monolithic.

In fact, I read a post by Linus few days back saying that Amiga OS is not microkernel. Linus was saying that Amiga OS is really monolithic kernel. No wonder people are getting confused and misinformed when you have Linus running around spreading lies like these. Guess Linus does not want other people to know the truth, otherwise he’d get pressured to switch Linux to hybrid or microkernel too. So, Linus goes around making stuff up. ie, making it look like everyone else is using monolithic kernels when in reality only Linux, Solaris & BSD are. So, Linus says hybrids do not exist, that microkernels are bad, bad, bad, etc. so people will side with him. But if people really look at both sides they’ll see that it’s just Linus’ strong opinion & bias and Linus has not proven anything.

I have a post blocked by spam filter that will show Linus saying Linux is bloated & inefficient in 2009! But Linus won’t admit that monolithic kernel has made the problem real bad for Linux. There is also a link to Ph.D computer science graduate that shows how Linus twists the truth to arrive to his biased conclusions!

[NoHaikuForMe]

[quote=phoudoin]
Actually, it’s not the linux kernel but its generic module probing mecanism that does this. Which also mean that, in fact, the realtek specific codec module (and any others installed) is also loaded at least during probing phase.[/quote]

I shall try to find time to write a more in-depth response, but ah, No. There is no “probing phase”.

If you read the code, sound/pci/hda/patch_realtek.c you will see the realtek codec module doesn’t even have a probe method. It consists just of code to be run for these HDA codecs, together with their IDs. There is no need for a probe method because the HDA driver is able to determine the codec ID for itself.

The “secret sauce” is a single line: MODULE_ALIAS(“snd-hda-codec-id:10ec*”);

The snd-hda-codec-id:10ec* string is baked into the module, and used by the userspace module tools to match it to requests from the kernel. Any codec with an ID beginning 10ec (Realtek’s vendor prefix) will cause this module to be loaded. Until it’s requested, none of this information needs to be in RAM. And once it has been loaded it can all be flushed when necessary.

This approach is used throughout Linux (and indeed by NT and presumably other modern systems that aspire to run on more than a handful of different people’s computers). There has been a project to try to introduce the same approach to Haiku, but it seems stalled. Here are some examples of such magic strings:

bt-proto-6 (Bluetooth HID) usb:v*p*d*dc*dsc*dp*ic01isc01ip* (general USB PCM audio) pcmcia:m01F1c0100f*fn*pfn*pa*pb*pc*pd* (a PC Card for laptop pro audio) acpi*:PNP0400:* (a PC parallel port reported via ACPI)

[NoHaikuForMe]

So now I actually had time to sit down with the Haiku source code and write a reply addressing the trickier part of your post.

[quote=phoudoin]
Well, the pages of code for these Realtek workaround will never be actually loaded because the HDA driver code itself will never trigger a (code) page fault to execute it.
Only a span of virtual memory pages is actually wasted, not physical memory.[/quote]

It would actually be possible (although fraught with danger) to do this, but Haiku doesn’t. Instead you can see

length = _kern_read(fd, programHeaders[i].p_offset, (void *)(region->start + (programHeaders[i].p_vaddr % B_PAGE_SIZE)), programHeaders[i].p_filesz);

The Haiku module loader routine simply reads the ELF sections into reserved kernel RAM. So all the realtek code (and everything else) is read from disk into RAM by this call. There is code to map an ELF image from a disk file into virtual addresses such that subsequent page faults bring it into RAM but so far as I was able to confirm that’s only used for userspace programs, not Haiku’s kernel add ons.

So in the end it does little difference, as on both platforms the hardware detection code of each codec supported must be loaded in physical memory and run and in both case only the code actually of some use is kept loaded that way.

As we see this isn’t true. Not only is there no need to load all this “hardware detection code” from every driver on Linux as I explained above, but Haiku does in fact load the entire driver into RAM.

[quote]
For code design consideration, Haiku HDA driver could be more modularized. But that will give us only lesser VM pages wasted, not physical ones. As the gain doesn’t seems to worth it, considering the few amount of active contributors skilled in this area the project has, nobody did it yet.

Patches are always welcome, though.
Be our guest.[/quote]

Of course, many of the things Haiku lacks are a result of your limited resources. But it does no good for people to insist that Haiku does this, or has that capability, when in fact it does not “for lack of resources”.

[phoudoin]

@NoHaikuForMe

There is no “probing phase”. […]
The “secret sauce” is a single line: MODULE_ALIAS(“snd-hda-codec-id:10ec*”);

Should be a recent design change then, because in my Ubuntu 9.04 (kernel 2.6.28.?), the HDA module codecs are still assembled all together (well, dependending on kernel config, that is) within a single module. It’s kinda hard to keep in touch with Linux sound system change, as there’s several. And chasing multiple targets is not that fun.

Anyway, that’s a nice move indeed, and our own HDA driver will be better if non-standard codec was indeed moved into separated kernel modules so only used one are kept loaded.

[quote=NoHaikuForMe]

[quote=phoudoin]
Well, the pages of code for these Realtek workaround will never be actually loaded because the HDA driver code itself will never trigger a (code) page fault to execute it.
Only a span of virtual memory pages is actually wasted, not physical memory.[/quote]

It would actually be possible (although fraught with danger) to do this, but Haiku doesn’t. Instead you can see

length = _kern_read(fd, programHeaders[i].p_offset, (void *)(region->start + (programHeaders[i].p_vaddr % B_PAGE_SIZE)), programHeaders[i].p_filesz);

The Haiku module loader routine simply reads the ELF sections into reserved kernel RAM.
So all the realtek code (and everything else) is read from disk into RAM by this call. There is code to map an ELF image from a disk file into virtual addresses such that subsequent page faults bring it into RAM but so far as I was able to confirm that’s only used for userspace programs, not Haiku’s kernel add ons.[/quote]
Well, the code above is not the culprid one for that but the B_FULL_LOCK requested for the area to host the read data. Anyway, you are right: the whole HDA driver code is loaded in memory. I dunno why I though we had a lazy load also for kernel add-ons with some hack to lock the ones installing interrupt handlers. Maybe it was once proposed but never made it into code.

So, I stand corrected : our HDA driver is bloated.

[quote]
Of course, many of the things Haiku lacks are a result of your limited resources. But it does no good for people to insist that Haiku does this, or has that capability, when in fact it does not “for lack of resources”.[/quote]

Yes, braging about capabilities Haiku has not actually does no good.
One thing that could do good to Haiku is that people spending time to fight against Haiku community’s pointless arguments will instead contribute the missing parts in Haiku.

After all, Linux is twice as old as Haiku, and had more than just twice its horsepower.
And no debate, flame, counter-argument or defense against whatever our community propaganda will improve Haiku more than, well, code contribution.
Everyone is free to spent his time as he want. But only time spent in doing actual contribution could change Haiku into a better Haiku…

One could simply start by filing en enhancement ticket in our Trac system, asking to split HDA codecs into submodules in order to reduce the code bloat loaded in kernel by the very commonly found and so used hda driver. That would be a good mark of willingness, too.

[NoHaikuForMe]

@phoudoin

Should be a recent design change then, because in my Ubuntu 9.04 (kernel 2.6.28.?), the HDA module codecs are still assembled all together

This change landed in 2.6.29, over two years ago. I suppose this is “recent” in terms of Haiku’s decade-plus lifecycle but most general purpose systems have a much faster turnover. When Haiku began (as OpenBeOS) the Intel HDA proposal did not exist.

After all, Linux is twice as old as Haiku, and had more than just twice its horsepower.

Indeed, however the decision not to use an existing, mature kernel was never forced upon Haiku’s developers. OpenBeOS (as it was then called) made an explicit decision to re-invent the wheel. If they want to revisit that decision now they don’t need a bug report to do that. But I suspect you will find that the sunk cost fallacy rules the day.

[phoudoin]

[quote=NoHaikuForMe][quote=phoudoin]
Should be a recent design change then, because in my Ubuntu 9.04 (kernel 2.6.28.?), the HDA module codecs are still assembled all together
[/quote]
This change landed in 2.6.29, over two years ago. I suppose this is “recent” in terms of Haiku’s decade-plus lifecycle but most general purpose systems have a much faster turnover. When Haiku began (as OpenBeOS) the Intel HDA proposal did not exist.[/quote]
And? Today both Linux and Haiku has HDA support.
Sure, since 2.6.29 the HDA linux driver is more modular than the Haiku’s one.
But it doesn’t make the later not working, just a lesser well designed one.

Indeed, however the decision not to use an existing, mature kernel was never forced upon Haiku’s developers. OpenBeOS (as it was then called) made an explicit decision to re-invent the wheel. If they want to revisit that decision now they don’t need a bug report to do that.

I fail to see the link here. Linux’s HDA driver was made more modular over two years ago, and for you that’s translate into a proof that Haiku should have use Linux kernel instead of his own?! Since when porting a driver needs to change the whole kernel too? When the price of this change is higher than write from scratch or a thin adapter layer, I fail to see the point, in particular when since start BeOS and Haiku were never an Unix operating system.

We’ve ported a good portion of xBSD network adapters drivers without switching to a BSD kernel. Why would we needs to do that for audio drivers? Even Linux kernel modules are not that dependent on kernel private API…

The “enhancement” report (it’s not buggy, just code bloated) was just about asking for HDA driver to be more modular than today, nothing more, nothing less. It’s not like all Haiku drivers have the same issues. It’s not like all Haiku audio drivers have either.

But thanks for staying on the non-contributing camp, all while saying that less contributors doesn’t explain most of the issues Haiku is still facing…

[Hubert]

[quote=MichaelPeppers]NT has modules, Haiku has kits, neither are microkernels, but you’re just denying the existence of hybrid kernels. Pal, this is not philosophy, there are some actual truths, and one is that, like it or not, hybrid kernels do exist and hybrid is not just a fancy word for monolithic.

Now, seriously, you obviously don’t like this OS and are entitled to your opinion, but why are you still posting here? I’m fairly sure you could do more productive things than looking for excuses to bash this project. If you think you can do better, code your own OS, if you don’t, well, search for one that suits your needs and help its team. Doing lengthy discussions about what’s it and what’s it not is just a huge waste of everyone’s time, including yours.

That said, I’m out of this discussion. Do whatever you want, I just don’t care enough to waste time here anymore.[/quote]

Michael do not be nervous, NoIntelligenceForMe err… NoHaikuForMe is a troll.
Please all do not feed a troll.

[NoHaikuForMe]

[quote=phoudoin]
I fail to see the link here.[/quote]

The kernel sub-project is hugely manpower intensive because of its unnecessarily large scope. It makes no sense to engage in such a project and then complain that you’re short of people. It’s like buying one last drink with your taxi money and then complaining that now you have to walk home.

All OpenBeOS actually needed was someone to tweak say, a BSD kernel to meet their requirements. This much smaller project would have resulted in access to a mature kernel and thus far broader hardware support, much improved portability, and all with less effort.

[phoudoin]

@NoHaikuForMe

The kernel sub-project is hugely manpower intensive because of its unnecessarily large scope.

It’s not anymore. Most work done in kernel land since a couple of years is not anymore in what is actually called “the kernel” but in drivers and their userland composants.
And when it comes to write hardware drivers, any alternative operating systems have a manpower issue. After 20 years, Linux has now enough market share to get some most complex and critic hardware (GPU, network adapters) support from their manufacturers themselves. The standardisation of several hardware busses and devices classes (AHCI, USB, ACPI, even HDA ) make this task more easier than it used to be 20 years ago when outside Windows your hardware had no support at all, and no technical datasheet from manufacters. This trend benefit Linux, but more even smaller alternative operating systems.

It makes no sense to engage in such a project and then complain that you’re short of people.

We don’t complain. Knowing and acknowledge that some drivers are not the best design they could be is not complaining. Otherwise, I’ll bet that pretty much every operating software developer is complaining, then.
You’re the one complaining that our HDA driver design is not good enough, which I acknowledge.
You want a better designed driver? Stop complaining about it and start contributing.
I’m not complaining about the lack of contributors, I’m just complaining about people complaining that an open (aka contributed by people for people) project is not good enough to their taste without seeing that it’s pointless: it’s not bad enough if you don’t care enough to actually do yourself something to improve it.

It’s like buying one last drink with your taxi money and then complaining that now you have to walk home.

Which, ironically, is a better solution than taxiing home earlier while you’re still quite drunk. Nothing better than a long walk to think about issues at hand

All OpenBeOS actually needed was someone to tweak say, a BSD kernel to meet their requirements. This much smaller project would have resulted in access to a mature kernel and thus far broader hardware support, much improved portability, and all with less effort.

Nobody will never knows because, well, simply nobody did it. Someones tries this path with Linux Kernel (the BluEyeOS project IIRC), but never reach critical mass.

Call it stupid[est] decision as much as you want but one thing remains: only Haiku reach “let’s rewritten BeOS in open source” critical mass. It doesn’t make it perfect, it’s doesn’t make it the only possible way to do it, but so far it’s the only one attempted which did it.

And it’s not an under-designed single audio hardware driver that will change that fact.

[X512]

I think, that running Haiku on Linux kernel is not hard task. To do this need to learn kernel to launch Haiku binaries, make accelerant, media_server, input_server and print_server add ons that work with Linux drivers and run bootsript when kernel initalize. No rebuild needed.

But I don’t think that Haiku kernel need to be abandoned. Haiku kernel is more compatible with multi-threading, more simple and fast.

[thatguy]

[quote=NoHaikuForMe][quote=phoudoin]
I fail to see the link here.[/quote]

The kernel sub-project is hugely manpower intensive because of its unnecessarily large scope. It makes no sense to engage in such a project and then complain that you’re short of people. It’s like buying one last drink with your taxi money and then complaining that now you have to walk home.

All OpenBeOS actually needed was someone to tweak say, a BSD kernel to meet their requirements. This much smaller project would have resulted in access to a mature kernel and thus far broader hardware support, much improved portability, and all with less effort.[/quote]

What part of “the developers didn’t want to use a server/unix kernel” didn’t you get ?

I for one would never consider using a linux kernel. I’d rather gouge out my eyes then untangle that sphagehtti mess of code.

[tonestone57]

[quote=thatguy]What part of “the developers didn’t want to use a server/unix kernel” didn’t you get?

I for one would never consider using a linux kernel. I’d rather gouge out my eyes then untangle that sphagehtti mess of code.[/quote]

To add, Linux kernel came out in 1991 and the GNU project has been looking to develop their own kernel (Hurd) for GNU OS which was based off Mach microkernel and now L4 microkernel. Just last year in 2010 did R. Stallman (GNU leader) finally give into Linux kernel. GNU project wanted to move away from Linux kernel because inefficient and huge which will only get worse over time. In big part because of monolithic design.

Linus wrote only the kernel & the GNU project created the rest of the OS for Linux.

If Linux kernel was so great & fast then why wouldn’t GNU just accept it sooner? Makes you wonder. Simply because GNU project wanted something better by realizing the drawbacks to monolithic design but were unable to deliver. There was little interest in making competing kernel & Linux kernel had become standard making it impossible to get developers to work on a GNU kernel.

NoHaiku is right that Linux kernel has been available and would give many drivers (that’s why Android OS uses it) but fails to say that it is huge, bloated & inefficient. ie, a real big mess

Haiku aims to be fast, clean and efficient which would get bogged down with the Linux kernel. Linux kernel would give trade off of greater hardware support for lesser performance.

[thatguy]

[quote=tonestone57][quote=thatguy]What part of “the developers didn’t want to use a server/unix kernel” didn’t you get?

I for one would never consider using a linux kernel. I’d rather gouge out my eyes then untangle that sphagehtti mess of code.[/quote]

To add, Linux kernel came out in 1991 and the GNU project has been looking to develop their own kernel (Hurd) for GNU OS which was based off Mach microkernel and now L4 microkernel. Just last year in 2010 did R. Stallman (GNU leader) finally give into Linux kernel. GNU project wanted to move away from Linux kernel because inefficient and huge which will only get worse over time. In big part because of monolithic design.

Linus wrote only the kernel & the GNU project created the rest of the OS for Linux.

If Linux kernel was so great & fast then why wouldn’t GNU just accept it sooner? Makes you wonder. Simply because GNU project wanted something better by realizing the drawbacks to monolithic design but were unable to deliver. There was little interest in making competing kernel & Linux kernel had become standard making it impossible to get developers to work on a GNU kernel.

NoHaiku is right that Linux kernel has been available and would give many drivers (that’s why Android OS uses it) but fails to say that it is huge, bloated & inefficient. ie, a real big mess

Haiku aims to be fast, clean and efficient which would get bogged down with the Linux kernel. Linux kernel would give trade off of greater hardware support for lesser performance.[/quote]

Actually the linux kernel has better overall throughput performance then haiku or BEOS or GNU Hurd minix and the NT kernels.

It does have that, but with that small 3-5% edge over some other kernels comes a huge mess of crap I personally don’t want to deal with it either. The biggest problem with linux is that it is essentially anarchy and no one is leading. Without leadership, focus and vision, you get a big mess.

haiku will continues to use code that makes sense and it fiarly well designed. I don’t have a problem with the hda driver either. Works fine for me.

[Earl_Colby_Pottinger]

Who do I talk to for help in writing drivers for Haiku?

I am trying to port/improve my old drivers from Beos to Haiku, the simple ones that support simple I/O work fine, but I am having real problems getting the more complex ones working.

I have been looking at the Haiku source code for weeks and just can’t seem to see my mistake - HELP!

For example, CRAM is seen by DiskProbe but not by DriveSetup so I can’t mount it.

I am trying to post this question to the Haiku-Development mailing group, but I seem to be messing up there too.

[thatguy]

[quote=Earl Colby Pottinger]Who do I talk to for help in writing drivers for Haiku?

I am trying to port/improve my old drivers from Beos to Haiku, the simple ones that support simple I/O work fine, but I am having real problems getting the more complex ones working.

I have been looking at the Haiku source code for weeks and just can’t seem to see my mistake - HELP!

For example, CRAM is seen by DiskProbe but not by DriveSetup so I can’t mount it.

I am trying to post this question to the Haiku-Development mailing group, but I seem to be messing up there too.[/quote]

did you create a account at freelists.org ? You have to create a account and then join the mailing list.

Once you do that your email will be sent.