How about /usr/include/rtnet_*.h instead? Are you aiming at getting
sockets code that wasn't designed with RTNet in mind to build without
modification?
} I'd like to get some comments on some of the following directions:
}
} 1. Creation of /usr/lib/realtime/include and population with header
} files.
}
} Currently, RTAI/RTLinux neutral projects (like RTnet and Comedi)
} don't have an adequate place to install header files for compilation
} with kernel modules. /usr/include is not appropriate, because it
} conflicts with existing files. (For example, RTnet can't use
} sockets.h, etc. because it aleady exists.) Comedi (with comedi.h)
} can use #ifdef __KERNEL__, but I don't feel that is a full
} solution.
I don't think include files belong in /usr/lib/. We're going for
/usr/include/rtlinux/ with 3.0 for include files. Our user-level libraries
go into /usr/lib/rtlinux/. We shouldn't conflict with anyone with those
places. How about if you stick things in /usr/{include,lib}/rtai/?
If we have similar include files then a package maintainer or builder that
uses one of the flavors just needs to change a '-I' line.
} Also, I'd like to see RTAI and RTLinux header files installed
} into /usr/lib/realtime/include/rtai and .../rtlinux, assuming
} that the respective maintainers are interested in the required
} amount of source-compatibility. (Don't need to be perfect here--
} we're all still learning.)
}
} Anything that has a user-space interface, such as fifos, will
} still want to install a /usr/include header file.
}
} (People familiar with cross compiling will realise that
} /usr/lib/realtime is probably the appropriate directory for
} this.)
How about /usr/include/rt_libc/. I like the idea of being able to switch
around with -I and not changing the source once it's done.
} 2. Development of some standard header files, such as stdlib.h, and
} a few of the libc functions that people have asked about on the
} mailing list.
}
} (I think this just needs someone to create the project.)
Do what we did, mail hpa or Linus and request a major/minor number. It
guarantees that you won't have anyone taking your #'s (any well behaved
code, that is) and you don't have to keep moving your #'s.
Since things are moving towards devfs, having an allocated major/minor will
help the move be less trouble.
} 3. Allocation of a real-time misc device major number.
}
} It appears that an increasing number of projects need access
} to a ioctl()-like interface, like Tomasz's shared memory and
} RTnet. Currently, both of these use unallocated/experimental
} Misc-device numbers, which eventually will lead to conflicts.
} I'd like to get these numbers permanently allocated, and I
} think a new major specifically for this purpose is a good idea,
} since it allows greater flexibility than using major 10,
} including autoloading of appropriate modules.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
