The FreeBSD-​linuxulator ex­plained (for de­velopers): ba­sics

The last post about the Linuxu­lator where I ex­plained the Linuxu­lator from an user point of view got some good amount of at­ten­tion. Triggered by a re­cent ex­plan­a­tion of the Linuxu­lator er­rno stuff to a fel­low FreeBSD de­veloper I de­cided so see if more de­velopers are in­ter­ested in some more info too…

The sy­scall vec­tor

In sys/​linux/linux_sysvec.c is all the ba­sic setup to handle Linux “sys­tem stuff” in FreeBSD. The “sys­tem stuff” is about trans­lat­ing FreeBSD er­rnos to Linux er­rnos, about trans­lat­ing FreeBSD sig­nals to Linux sig­nales, about hand­ling Linux traps, and about set­ting up the FreeBSD sys­tem vec­tor (the ker­nel struc­ture which con­tains all the data to identify when a Linux pro­gram is called and to be able to lookup the right ker­nel func­tions for e.g. sy­scalls and ioctls).

There is not only one sy­scall vec­tor, there is one for a.out (struct sysentvec linux_​sysvec) and one for ELF (struct sysentvec elf_​linux_​sysvec) bin­ar­ies (at least on i386, for other ar­chi­tec­tures it may not make sense to have the a.out stuff, as they maybe never seen any a.out Linux bin­ary).

The ELF AUX args

When an ELF im­age is ex­ecuted, the Linuxu­lator adds some runtime in­form­a­tion (like pages­ize, uid, guid, …) so that the user­land can query this in­form­a­tion which is not static at build-​time eas­ily. This is handled in the elf_​linux_​fixup func­tion(). If you see some er­ror mes­sages about miss­ing ELF notes from e.g. glibc, this is the place to add this in­form­a­tion to. It would not be bad from time to time to have a look what Linux is provid­ing and miss­ing pieces there. FreeBSD does not has an auto­mated way of do­ing this, and I am not aware of someone who reg­u­larly checks this. There is a little bit more info about ELF notes avail­able in a mes­sage to one of the FreeBSD mail­ing lists, it also has an ex­ample how to read out this data.

Traps

Linux and FreeBSD do not share the same point of view how a trap shall be handled (SIGBUS or SIGSEGV), the cor­res­pond­ing de­cision mak­ing is handled in translate_​traps() and a trans­la­tion table is avail­able as _​bsd_​to_​linux_​trapcode.

Sig­nals

The val­ues for the sig­nal names are not the same in FreeBSD and Linux. The trans­la­tion tables are called linux_​to_​bsd_​signal and bsd_​to_​linux_​signal. The trans­la­tion is a fea­ture of the sy­scall vec­tor (= auto­matic).

Er­rnos

The val­ues for the er­rno names are not the same in FreeBSD and Linux. The trans­la­tion table is called bsd_​to_​linux_​errno. Re­turn­ing an er­rno in one of the Linux sy­scalls will trig­ger an auto­matic trans­la­tion from the FreeBSD er­rno value to the Linux er­rno value. This means that FreeBSD er­rnos have to be re­turned (e.g. FreeBSD ENOSYS=78) and the Linux pro­gram will re­ceive the Linux value (e.g. Linux ENOSYS=38, and as the Linux ker­nel re­turns neg­at­ive er­rnos, the linux pro­gram will get –38).

If you see some­where an “-ESOMETHING” in the Linuxu­lator code, this is either a bug, or some clever/​tricky/​dangerous use of the sign-​bit to en­code some info (e.g. in the fu­tex code there is a func­tion which re­turns –ENOSYS, but the sign-​bit is used as an er­ror in­dic­ator and the call­ing code is re­spons­ible to trans­late neg­at­ive er­rnos into pos­it­ive ones).

Sy­scalls

The Linux sy­scalls are defined sim­ilar to the FreeBSD ones. There is a map­ping table (sys/linux/syscalls.master) between sy­scall num­bers and the cor­res­pond­ing func­tions. This table is used to gen­er­ate code (“make sysent” in sys/​/​linux/​) which does what is ne­ces­sary.

StumbleUponXINGBalatarinBox.netDiggGoogle GmailNetvouzPlurkSiteJotTypePad PostYahoo BookmarksVKSlashdotPocketHacker NewsDiigoBuddyMarksRedditLinkedInBibSonomyBufferEmailHatenaLiveJournalNewsVinePrintViadeoYahoo MailAIMBitty BrowserCare2 NewsEvernoteMail.RuPrintFriendlyWaneloYahoo MessengerYoolinkWebnewsStumpediaProtopage BookmarksOdnoklassnikiMendeleyInstapaperFarkCiteULikeBlinklistAOL MailTwitterGoogle+PinterestTumblrAmazon Wish ListBlogMarksDZoneDeliciousFlipboardFolkdJamespotMeneameMixiOknotiziePushaSvejoSymbaloo FeedsWhatsAppYouMobdiHITTWordPressRediff MyPageOutlook.comMySpaceDesign FloatBlogger PostApp.netDiary.RuKindle ItNUjijSegnaloTuentiWykopTwiddlaSina WeiboPinboardNetlogLineGoogle BookmarksDiasporaBookmarks.frBaiduFacebookGoogle ClassroomKakaoQzoneSMSTelegramRenrenKnownYummlyShare/​Save

Jumstart/​JET for FreeBSD (brain­storm­ing)

There are some HOW­TOs out there in the net which de­scribe some auto­matic net­work based in­stall via PXE-​booting a ma­chine from a server which has a spe­cific FreeBSD re­lease in the PXE-​booting area and a non-​interactive con­fig for sys­in­stall to in­stall this FreeBSD ver­sion on the ma­chine which PXE-​boots this.

The setup of this is com­pletely manual and only al­lows to net­boot one FreeBSD ver­sion. The server-​side setup for the cli­ents is also com­pletely manual (and only al­lows to in­stall one cli­ent at a time, it seems). This is not very user-​friendly, and far away from the power of Jumpstart/​JET for Sol­aris where you cre­ate a tem­plate (maybe from an­other tem­plate with auto­matic value (IP, name, MAC) re­place­ment) and can spe­cify dif­fer­ent OS re­leases for dif­fer­ent cli­ents and then just run a com­mand to gen­er­ate a good con­fig for this.

I thought a little bit how it could be done and de­cided to write down all the stuff (so far 160 lines, 830 words) to not for­get some de­tails. All in all I think this could be done (at least a sens­ible sub­set) in a week or two (full­time) if you have the hard­ware, mo­tiv­a­tion, and time. As al­ways, the prob­lems are within the de­tails, so I may be off with my es­tim­a­tion a little bit (also de­pends upon the knowledge-​level (shell, tftp, dh­cpd, in­stall–soft­ware) of the per­son do­ing this).

Un­for­tu­nately I do not know if I have the hard­ware at home to do some­thing like this. I have some un­used hard­disks which could be used in a ma­chine which is used tem­por­ary as a test-​install-​client (nor­mally I use this ma­chines as my Desktop… if I do not use my little Net­book in­stead, as I do not do much at home cur­rently), but I’ve never checked if this ma­chine is PXE-​booting-​capable (VIA KT133 chip­set with a 3Com 3c905C-​TX Fast Eth­er­link XL). I also do not have the time to do this (with the cur­rent rate of free time I would ex­pect to need about a year), ex­cept maybe someone would call my boss and ne­go­ti­ate some­thing.

I can not re­mem­ber any re­quest to have some­thing like this on the freebsd-​current, freebsd-​arch or freebsd-​hackers list since I read them (and that is since about at least 3.0-RELEASE). Is this be­cause nearly nobody is in­ter­ested in some­thing like this, or are the cur­rent pos­sib­il­it­ies enough for your needs? Do you work at a place where this would be wel­come (= dir­ectly used when it would be done)? If you use a simple solu­tion to make a net-​install, what is your ex­per­i­ence with this (pros/​cons)?

Sol­aris 10 up­date 9: the not so nice things about it

I up­dated some work­sta­tions of the cli­ent to Sol­aris 10 up­date 9. Upon in­stalling my xorg.conf (dual-​screen setup) I had to no­tice that it does not work any­more. The prob­lem is, that the NVidia driver does not con­tain sup­port for the graphic card we use.

Nor­mally this is not a big deal, this can hap­pen… but in this case this is about SUN Ul­tra 20 work­sta­tions with SUN provided NVidia Quat­tro FX (NV37GL) cards. Ok, they are not the most re­cent ones, they where bought 4 – 5 years ago, but still, they just work as needed here and the cur­rent Sol­aris re­lease has no out-​of-​the-​box sup­port for them. I would ex­pect this to work already in a fresh in­stall (yes, I was not able to get the nv driver to work with two screens on this graphic card, it seems the nv driver has not sup­port for this).

Solu­tion for me: down­load the old driver from NVidia and in­teg­rate it into Jump­start (but still, some hours are lost be­cause of first try­ing to get a work­ing dual-​screen setup with the nv driver be­fore tak­ing an old NVidia driver and us­ing it like be­fore in xorg.conf).

An­other glitch a co-​worker dis­covered is that StarOf­fice is not in­cluded any­more. That is again some­thing which will cause some loss of time. I will have to have a look how to handle it. Prob­ably it is best to in­stall it on the server and mount it via NFS on the work­sta­tions. I will see soon if this is can be done (in­stall­a­tion of OO into a spe­cific place which can be shared) or not.

Rant about Berke­leyDB docs

I was build­ing Berke­leyDB (4.7, yes I know, there are more re­cent ver­sions avail­able) on a Sol­aris ma­chine. First try was to un­pack, cd into the dir­ect­ory, run con­fig­ure. It failed, there is no con­fig­ure script. Bah. 🙁

Second try: search­ing for docs… found some… in HTML (the README refers to it and tells noth­ing else). This is a re­mote ma­chine, I do not want to use a HTML browser re­motely (I may not even have one in­stalled there…). Bah. 🙁

Ok, dist/​configure ex­ists, no spe­cial op­tions needed for my case, it seems.

There is even a Sol­aris spe­cific HTML file, but from a quick glance at it with „less“, it looks like a FAQ.

Us­ab­il­ity from a com­mand line: zero.
Pos­sib­il­ity to com­pile from a GUI (unix): I doubt it.

What is wrong with plain text files? If I down­load the source and want to com­pile it (and for Sol­aris this is the nor­mal way of work­ing), why the hell do I need some GUI in­stead of get­ting a plain text file with the re­quired de­scrip­tion (which is not graph­ic­ally en­hanced in the HTML ver­sion either)? You can even gen­er­ate a plain text ver­sion of the docs auto­mat­ic­ally dur­ing the src-​packaging pro­cess.

Hey Or­acle, there is room for im­prove­ment here!

Fight­ing with the Or­acle Dir­ect­ory Server 7 (DSEE7) on Sol­aris 10 up­date 9

After mov­ing our sec­ond­ary man­age­ment site (our team is split up into 2 dif­fer­ent loc­a­tions) to a new build­ing, we de­cided to clean-​up some things. One of those things in­volves mov­ing the LDAP to a dif­fer­ent ma­chine (more or less a new server for the new site, it is in­de­pend­ent re­gard­ing LDAP/​homes/​… from the primary site). While I am at it, I take the op­por­tun­ity to move from DSEE5 to DSEE7 (my pre­vi­ous post about the DSEE6 mi­gra­tion was at the primary site). This time I took the pack­age dis­tri­bu­tion in­stead of the zip dis­tri­bu­tion (the main reason is that I can get patch-​listings with an auto­matic tool, and the sec­ond­ary man­age­ment site has no disaster-​recovery re­quire­ments for the ap­plic­a­tions… we just will setup a new sec­ond­ary site some­where else if ne­ces­sary).

Here my ex­per­i­ences with the in­stall­a­tion in­struc­tions of DSEE7.

  • The in­stall in­struc­tions refer to the web in­ter­face for the DSEE7 man­age­ment, but I have not seen some­thing which tells you first have to setup an ap­plic­a­tion server (this was bet­ter in the DSEE6 in­struc­tions).
  • When us­ing the Glassfish ap­plic­a­tion server which comes with Sol­aris 10 for the web in­ter­face, you will get an ex­cep­tion after de­ploy­ing the dscc7.war, as it is us­ing an out­dated JVM. After some fight­ing and Googling, I found that I have to change the AS_​JAVA value in /​usr/​appserver/​con­fig/asenv.conf to a more re­cent JVM as it is point­ing to the very out­dated j2se 1.4.x. I poin­ted it to /​usr/​java (which is a sym­link to the most re­cent ver­sion in­stalled as a pack­age). In­stead of the ori­ginal ex­cep­tion I got an­other one now (after a re­dir­ec­tion in the web–browser), some­thing that it can not find the Ant­Main class (Glassfish uses ANT from /​usr/​sfw, this is the one which comes with Sol­aris 10 up­date 9). I tried with Java 5 in­stead of Java 6, but I get the same er­ror. In the net there are some dis­cus­sions about such er­rors (it is even a FAQ at the ANT site), but this Glassfish/​DSEE7 thing is a black box for me, so what am I sup­posed to do here (I do not want to put the sys­tem into an un­of­fi­cial state by in­stalling my own ANT for Glassfish/​DSEE7)?
    It was not men­tioned in the Ap­pendix of the DSEE7 in­stall in­struc­tions which ex­plains how to in­stall the .war in Glassfish that you have to change to a more re­cent JVM, and I still fight with the Ant­Main prob­lem (hey Or­acle, there is room for im­prove­ment in the product com­pat­ib­il­ity test­ing and doc­u­ment­a­tion veri­fic­a­tion pro­cess).

I will up­date this post­ing when I make some ad­vance­ments. For now I let the web in­ter­face in the bad state as it is and con­cen­trate on fin­ish­ing the LDAP move to the new sys­tem (in­stalling an DSEE on a backup sys­tem, con­fig­ur­ing rep­lic­a­tion, switch­ing the cli­ents to them). The web in­ter­face is in­de­pend­ent enough to handle it later (hints wel­come, that is the main pur­pose why I write this pos­ing in the middle of the work).