If not why not? It seems as though reading, writing, and appending to it would be far more flexible provided multi instance and multi-user issues are accounted for.
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
If not why not? It seems as though reading, writing, and appending to it would be far more flexible provided multi instance and multi-user issues are accounted for.
No..
The operating system is not for GUI/Application layer semantics it only provides the raw abstraction to present a consistent, pretty system to user-space applications. If you want to do something like this, I would advise you write a system daemon that applications can use as a copy store and access through system IPC such as DBus.
Standards in the freedesktop.org standards may define standards for GUI interoperability and advise they communicate through something like DBus.
Rather than a kernel space system, you may want to manage copy and paste semantics above OS services such as IPC and keep the policy in user-land but through operating system mechanics.
Whilst a device driver presentation kind-of makes sense, IMHO it belongs in user-space as some kind of mini-database with source/target data and meta-data relating to encoding and so on … none of which are strictly kernel concerns.
Please don’t write a copy/paste device driver 🙂
edit toned down the bolding ..