Opened 16 years ago
Closed 16 years ago
#3410 closed bug (invalid)
CAM.h should be in /boot/develop/headers/os/drivers/CAM.h as in BeOS
Reported by: | schily | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | - General | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
CAM has no own hardware and is a pseudo driver.
cdrtools like to see the file on the same location as with BeOS
Change History (9)
comment:1 by , 16 years ago
follow-up: 5 comment:2 by , 16 years ago
CAM.h is used in userland by libscg from cdrecord.
libscg/scsi-beos.c includes <drivers/CAM.h> If the file stays where it currently is, it breaks compiling cdrtools.
comment:3 by , 16 years ago
While Haiku is still a moving target (and thus these things could be changed), we do not necessarily provide 100% source compatibility, so if that header has been moved for a reason that's okay.
We also dropped BEOS as Haiku provides a much better POSIX experience, and ports should definitely be revisited in this regard.
Just as general information, I haven't really looked into the issue at hand :-)
comment:4 by , 16 years ago
It would be nice is there was stability in the interfaces and I understand the include paths as part of the interfaces.
What was the reason to change the include path compared to BeOS 5 or Zeta?
comment:5 by , 16 years ago
Replying to schily:
CAM.h is used in userland by libscg from cdrecord.
libscg/scsi-beos.c includes <drivers/CAM.h> If the file stays where it currently is, it breaks compiling cdrtools.
Including Be API headers with a directory part has been discouraged for ages. Just include <CAM.h> and it will work fine.
comment:6 by , 16 years ago
When was the change to allow #include <CAM.h> introduced?
Was it with BeOS 5, Zeta or Haiku?
comment:7 by , 16 years ago
Description: | modified (diff) |
---|
That already happened for BeOS, I just don't know if it was R5 or earlier.
comment:9 by , 16 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
I hope it's OK to close (not really invalid but as there is no fix).
As I put in a comment on the mailing list, within the os headers, a header goes to device if it is used in userland, and to driver if it is used in kernel land. CAM.h is a bus_manager and as such used in kernel land, so the move would be a proper one.
Could you verify if any part of the build breaks when this file is moved from device to drivers?