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$
|
|
|
|
|
2009-12-06 20:30:21 +00:00
|
|
|
.include <bsd.own.mk>
|
|
|
|
|
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
|
|
|
LIB= ulog
|
|
|
|
SHLIB_MAJOR= 0
|
2009-12-06 20:30:21 +00:00
|
|
|
INCS= ulog.h utempter.h
|
2009-12-05 19:53:29 +00:00
|
|
|
SRCS= ulog.h ulog_getutxent.c ulog_internal.h ulog_login.c \
|
2009-12-06 20:30:21 +00:00
|
|
|
ulog_login_pseudo.c ulog_pututxline.c ulog_util.c utempter.c
|
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
|
|
|
|
2009-12-06 20:30:21 +00:00
|
|
|
MAN= ulog_getutxent.3 ulog_login.3 ulog_setutxfile.3 \
|
|
|
|
utempter_add_record.3
|
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
|
|
|
MLINKS+=ulog_getutxent.3 ulog_endutxent.3 \
|
2009-12-05 19:53:29 +00:00
|
|
|
ulog_getutxent.3 ulog_getutxline.3 \
|
|
|
|
ulog_getutxent.3 ulog_pututxline.3 \
|
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_getutxent.3 ulog_setutxent.3 \
|
|
|
|
ulog_login.3 ulog_login_pseudo.3 \
|
|
|
|
ulog_login.3 ulog_logout.3 \
|
2009-12-05 19:53:29 +00:00
|
|
|
ulog_login.3 ulog_logout_pseudo.3 \
|
2009-12-06 20:30:21 +00:00
|
|
|
ulog_setutxfile.3 ulog_getutxuser.3 \
|
|
|
|
utempter_add_record.3 utempter_remove_added_record.3 \
|
|
|
|
utempter_add_record.3 utempter_remove_record.3 \
|
|
|
|
utempter_add_record.3 addToUtmp.3 \
|
|
|
|
utempter_remove_added_record.3 removeFromUtmp.3 \
|
|
|
|
utempter_remove_record.3 removeLineFromUtmp.3
|
2009-12-05 19:53:29 +00:00
|
|
|
|
|
|
|
# Add links to <utmpx.h>-style functions.
|
|
|
|
MLINKS+=ulog_endutxent.3 endutxent.3 \
|
|
|
|
ulog_getutxent.3 getutxent.3 \
|
|
|
|
ulog_getutxline.3 getutxline.3 \
|
|
|
|
ulog_pututxline.3 pututxline.3 \
|
|
|
|
ulog_setutxent.3 setutxent.3
|
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
|
|
|
|
|
|
|
WARNS?= 6
|
|
|
|
|
|
|
|
VERSION_DEF= ${.CURDIR}/../libc/Versions.def
|
|
|
|
SYMBOL_MAPS= ${.CURDIR}/Symbol.map
|
|
|
|
|
2009-12-06 20:30:21 +00:00
|
|
|
.if ${MK_INSTALLLIB} != "no"
|
|
|
|
SYMLINKS+=libulog.a ${LIBDIR}/libutempter.a
|
|
|
|
.endif
|
|
|
|
.if !defined(NO_PIC)
|
|
|
|
SYMLINKS+=libulog.so ${LIBDIR}/libutempter.so
|
|
|
|
.endif
|
|
|
|
.if ${MK_PROFILE} != "no"
|
|
|
|
SYMLINKS+=libulog_p.a ${LIBDIR}/libutempter_p.a
|
|
|
|
.endif
|
|
|
|
|
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
|
|
|
.include <bsd.lib.mk>
|