Subject: Re: sample utmpx implementation
To: Christos Zoulas <email@example.com>
From: John Nemeth <firstname.lastname@example.org>
Date: 12/05/2001 05:52:36
On Apr 13, 5:33am, Christos Zoulas wrote:
} On Nov 21, 2:51am, email@example.com (John Nemeth) wrote:
} | } - The lastlog stuff is missing
} | } I am thinking of implementing lastlog using db, so that it does not
} | } become huge like it is now.
} | lastlog is a constant size. It also has holes, so it isn't any
} | larger then needed. Making it a db would greatly increase the size and
} | considerably complicate access. I really don't like this idea. Also,
} | any reason you didn't add any padding to struct lastlogx? Off the top
} | of my head, I can't think of any other fields that are needed, but that
} | is the whole reason for padding.
} You are right, I will add padding. I am not sure about the complicating
} access issue. I'd rather have a routine abstracting the complex access,
} than exposing the simplistic access method we currently have. Having
I don't see any routines for accessing lastlog on Solaris 8.
There doesn't seem to be any precedent for doing anything other than
using the UID to seek and read. How do you plan on getting people to
switch to a library routine.
} huge files with holes does not appeal to me.
This sounds like an aesthetics argument, not a technical argument
} | I didn't see any functions for handling wtmpx records. Solaris
} | 2.5 provides these functions:
} | [snip]
} Ok, I'll look into implementing those.
Hmm... I guess I should have provided the prototypes:
void updwtmp(char *wfile, struct utmp *utmp);
void updwtmpx(char *wfilex, struct utmpx *utmpx);
}-- End of excerpt from Christos Zoulas