Add a new library: libulog.
One of the things I really want to do, is to get rid of the limitations
of our current utmp(5) mechanism:
- It only allows 8 byte TTY device names.
- The hostname only allows 16 bytes of storage.
I'm not a big fan of <utmpx.h>, but I think we should at least try to
add parts of it. Unfortunately we cannot implement <utmpx.h>, because we
miss various fields, such as ut_id, ut_pid, etc. The API provided by
libulog shares some similarities with <utmpx.h>, so it shouldn't be too
hard to port these applications eventually. In most simple cases, it
should just be a matter of removing the ulog_ prefix everywhere.
As a bonus, it also implements a function called ulog_login_pseudo(),
which allows unprivileged applications to write log entries, provided
they have a valid file descriptor to a pseudo-terminal master device.
libulog will allow a smoother transition to a new file format by adding
a library interface to deal with utmp/wtmp/lastlog files. I initially
thought about adding the functionality to libutil, but because I'm not
planning on keeping this library around forever, we'd better keep it
separated.
Next items on the todo list:
1. Port applications in the base system (and ports) to libulog, instead
of letting them use <utmp.h>.
2. Remove <utmp.h>, implement <utmpx.h> and reimplement this library on
top.
3. Port as many applications as possible back to <utmpx.h>.
2009-12-03 15:48:24 +00:00
|
|
|
/*
|
|
|
|
|
* $FreeBSD$
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
FBSD_1.2 {
|
|
|
|
|
ulog_endutxent;
|
|
|
|
|
ulog_getutxent;
|
2009-12-05 19:53:29 +00:00
|
|
|
ulog_getutxline;
|
|
|
|
|
ulog_getutxuser;
|
Add a new library: libulog.
One of the things I really want to do, is to get rid of the limitations
of our current utmp(5) mechanism:
- It only allows 8 byte TTY device names.
- The hostname only allows 16 bytes of storage.
I'm not a big fan of <utmpx.h>, but I think we should at least try to
add parts of it. Unfortunately we cannot implement <utmpx.h>, because we
miss various fields, such as ut_id, ut_pid, etc. The API provided by
libulog shares some similarities with <utmpx.h>, so it shouldn't be too
hard to port these applications eventually. In most simple cases, it
should just be a matter of removing the ulog_ prefix everywhere.
As a bonus, it also implements a function called ulog_login_pseudo(),
which allows unprivileged applications to write log entries, provided
they have a valid file descriptor to a pseudo-terminal master device.
libulog will allow a smoother transition to a new file format by adding
a library interface to deal with utmp/wtmp/lastlog files. I initially
thought about adding the functionality to libutil, but because I'm not
planning on keeping this library around forever, we'd better keep it
separated.
Next items on the todo list:
1. Port applications in the base system (and ports) to libulog, instead
of letting them use <utmp.h>.
2. Remove <utmp.h>, implement <utmpx.h> and reimplement this library on
top.
3. Port as many applications as possible back to <utmpx.h>.
2009-12-03 15:48:24 +00:00
|
|
|
ulog_login;
|
|
|
|
|
ulog_login_pseudo;
|
|
|
|
|
ulog_logout;
|
|
|
|
|
ulog_logout_pseudo;
|
2009-12-05 19:53:29 +00:00
|
|
|
ulog_pututxline;
|
Add a new library: libulog.
One of the things I really want to do, is to get rid of the limitations
of our current utmp(5) mechanism:
- It only allows 8 byte TTY device names.
- The hostname only allows 16 bytes of storage.
I'm not a big fan of <utmpx.h>, but I think we should at least try to
add parts of it. Unfortunately we cannot implement <utmpx.h>, because we
miss various fields, such as ut_id, ut_pid, etc. The API provided by
libulog shares some similarities with <utmpx.h>, so it shouldn't be too
hard to port these applications eventually. In most simple cases, it
should just be a matter of removing the ulog_ prefix everywhere.
As a bonus, it also implements a function called ulog_login_pseudo(),
which allows unprivileged applications to write log entries, provided
they have a valid file descriptor to a pseudo-terminal master device.
libulog will allow a smoother transition to a new file format by adding
a library interface to deal with utmp/wtmp/lastlog files. I initially
thought about adding the functionality to libutil, but because I'm not
planning on keeping this library around forever, we'd better keep it
separated.
Next items on the todo list:
1. Port applications in the base system (and ports) to libulog, instead
of letting them use <utmp.h>.
2. Remove <utmp.h>, implement <utmpx.h> and reimplement this library on
top.
3. Port as many applications as possible back to <utmpx.h>.
2009-12-03 15:48:24 +00:00
|
|
|
ulog_setutxent;
|
2009-12-05 19:53:29 +00:00
|
|
|
ulog_setutxfile;
|
Add a new library: libulog.
One of the things I really want to do, is to get rid of the limitations
of our current utmp(5) mechanism:
- It only allows 8 byte TTY device names.
- The hostname only allows 16 bytes of storage.
I'm not a big fan of <utmpx.h>, but I think we should at least try to
add parts of it. Unfortunately we cannot implement <utmpx.h>, because we
miss various fields, such as ut_id, ut_pid, etc. The API provided by
libulog shares some similarities with <utmpx.h>, so it shouldn't be too
hard to port these applications eventually. In most simple cases, it
should just be a matter of removing the ulog_ prefix everywhere.
As a bonus, it also implements a function called ulog_login_pseudo(),
which allows unprivileged applications to write log entries, provided
they have a valid file descriptor to a pseudo-terminal master device.
libulog will allow a smoother transition to a new file format by adding
a library interface to deal with utmp/wtmp/lastlog files. I initially
thought about adding the functionality to libutil, but because I'm not
planning on keeping this library around forever, we'd better keep it
separated.
Next items on the todo list:
1. Port applications in the base system (and ports) to libulog, instead
of letting them use <utmp.h>.
2. Remove <utmp.h>, implement <utmpx.h> and reimplement this library on
top.
3. Port as many applications as possible back to <utmpx.h>.
2009-12-03 15:48:24 +00:00
|
|
|
};
|