implement <utmpx.h>

[kaliber]

It would be nice to have utmpx support in haiku: ​http://www.opengroup.org/onlinepubs/009695399/basedefs/utmpx.h.html

[michaelvoliveira]

FreeBSD already did it

​http://lists.freebsd.org/pipermail/freebsd-current/2010-January/014893.html

[vibhavp]

I think this should do the work:

/* As of now, Haiku doesnt have multiuser support, this header provides a stub implementation */ #include <sys/types.h> #include <sys/time.h>

struct utmpx {

char ut_user[]; /* User login name */ char ut_it[]; /* Unspecified initialization process identifier. */ char ut_line[]; /* Device name */ pid_t ut_id; /* Process ID */ short ut_type; /* Type of entry */ struct timeval ut_tv; /* Time entry was made */

}

/* Symbolic constants for ut_type */ #define EMPTY 0 /* No valid user accounting information. */ #define BOOT_TIME 1 /* Identifies time of system boot. */ #define OLD_TIME 2 /* Identifies time when system clock changed. */ #define NEW_TIME 3 /* Identifies time after system clock changed. */ #define USER_PROCESS 4 /* Identifies a process. */ #define INIT_PROCESS 5 /* Identifies a process spawned by the init process. */ #define LOGIN_PROCESS 6 /* Identifies the session leader of a logged-in user */ #define DEAD_PROCESS 7 /* Identifies a session leader who has exited. */

void endutxent(void); struct utmpx *getutxent(void); struct utmpx *getutxid(const struct utmpx *); struct utmpx *getutxline(const struct utmpx *); struct utmpx *pututxline(const struct utmpx *); void setutxent(void);

[siarzhuk]

Please use the GCI task page for communication with your mentors. AFAIK results of your work should be provided as standard git formatted patches. Read "git format-patch help" for more info. So please avoid publishing raw code as ticket comments. Thank you.

[bonefish]

A few general remarks:

• I don't see any point in having a stub implementation. The only effect this will have is that the configure script of ported software packages that can make use of this functionality will think Haiku provides it, although it actually doesn't.
• Haiku does have basic support for multi-user. Besides that the kernel doesn't enforce all user permissions correctly (most FSs actually do, but in other places users may do things they shouldn't be allowed to) the needed parts should mostly be in place. We're missing certain APIs (like this user accounting database stuff) and at the system application level (servers) there's quite a bit to be done to make it work despite enforced user permissions.
• The pointer style type* foo should be preferred over type *foo.

[siarzhuk]

Replying to bonefish:

• I don't see any point in having a stub implementation.

I'm completely agree with you. Unfortunately I have cleared all details of this problem after the student has already claimed the task and started implementation in stub variant. :-(

But if you find the full-blown implementation reasonable at the current moment - the follow-up GCI task can be created - to finish this implementation. But, please, share in this case your vision about implementation details. Thanks.

[vibhavp]

Replying to siarzhuk:

Replying to bonefish:

• I don't see any point in having a stub implementation.

I'm completely agree with you. Unfortunately I have cleared all details of this problem after the student has already claimed the task and started implementation in stub variant. :-(

But if you find the full-blown implementation reasonable at the current moment - the follow-up GCI task can be created - to finish this implementation. But, please, share in this case your vision about implementation details. Thanks.

I am working on a full-blown implementation for utmpx.h. You can create a follow-up task on the latter and post it's link here. I will be more than happy to provide you with the patches :)

[bonefish]

Replying to siarzhuk:

But if you find the full-blown implementation reasonable at the current moment - the follow-up GCI task can be created - to finish this implementation. But, please, share in this case your vision about implementation details. Thanks.

I don't have a vision about the implementation ATM. I have a rough idea of the purpose of the user accounting functionality -- from which I would say that it can be implemented in the current Haiku -- but I don't know any details. A reasonable approach would be to first find out, how this DB is actually used. I don't mean the API -- the POSIX specs cover that -- but which program/component uses the API when and how. Also, there are no removal operations in the API, so the DB must either be cleared and/or culled at some point (at boot?).

Once all that is clear, we can think of how an appropriate implementation could look like on Haiku.

[luroh]

Move POSIX compatibility related tickets out of R1 milestone (FutureHaiku/Features).

[jackburton]

Gnu screen does use this functionality.

[jackburton]

Replying to bonefish:

Replying to siarzhuk:

I don't have a vision about the implementation ATM. I have a rough idea of the purpose of the user accounting functionality -- from which I would say that it can be implemented in the current Haiku -- but I don't know any details. A reasonable approach would be to first find out, how this DB is actually used. I don't mean the API -- the POSIX specs cover that -- but which program/component uses the API when and how. Also, there are no removal operations in the API, so the DB must either be cleared and/or culled at some point (at boot?).

Once all that is clear, we can think of how an appropriate implementation could look like on Haiku.

When you say "which program/component uses the API when and how", you mean we should define which native Haiku components (IE: Servers and applications) should update the db and how and when ?

[korli]

OpenJDK14 thinks this is POSIX and expects header and symbols, functional isn't required. ​https://review.haiku-os.org/c/haiku/+/3371

[korli]

Header and symbols merged in hrev54720. Lynx seems to be affected... see ​https://github.com/haikuports/haikuports/pull/5772