Opened 11 years ago

Last modified 23 months ago

#3207 new enhancement

implement <utmpx.h>

Reported by: kaliber Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: System/POSIX Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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

Attachments (2)

0001-Add-a-stub-implementation-for-utmpx.h.patch (3.1 KB ) - added by vibhavp 7 years ago.
0001-Added-stub-implementation-for-utmpx.h.patch (3.4 KB ) - added by vibhavp 7 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 by bonefish, 10 years ago

Component: System/libroot.soSystem/POSIX
Owner: changed from axeld to nobody

comment:3 by vibhavp, 7 years ago

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);

Version 0, edited 7 years ago by vibhavp (next)

comment:4 by siarzhuk, 7 years ago

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.

comment:5 by vibhavp, 7 years ago

Has a Patch: set

comment:6 by vibhavp, 7 years ago

Has a Patch: unset

comment:7 by vibhavp, 7 years ago

Has a Patch: set

comment:8 by bonefish, 7 years ago

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.

in reply to:  8 ; comment:9 by siarzhuk, 7 years ago

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.

in reply to:  9 comment:10 by vibhavp, 7 years ago

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 :)

in reply to:  9 ; comment:11 by bonefish, 7 years ago

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.

comment:12 by luroh, 5 years ago

Milestone: R1Unscheduled

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

comment:13 by jackburton, 4 years ago

Gnu screen does use this functionality.

in reply to:  11 comment:14 by jackburton, 4 years ago

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 ?

Last edited 4 years ago by jackburton (previous) (diff)

comment:15 by waddlesplash, 23 months ago

Has a Patch: unset
Note: See TracTickets for help on using tickets.