June Daemon News out and about

BSDJoe writes "The June daemonnews newsletter has been posted" Included in this issue are an introduction to the ports system, a length tutorial devoted to writing writing a CAM SCSI controller driver, and a great editorial about how to attract users without dumbing down.

NP:-foo

[howardjp]

Okay Nik, what is up with the NP always in the department name?

Assembly and Ports

[questionlp]

This month's issue of Daemon News has a very nice summary and overview of the Ports system and how to use it and how it's done. I haven't worked with Debian nor the apt-get utility, but the BSD ports system is definitely one of BSD's high points.

The only gripe I have with the ports system is that I don't always update the ports directory on my workstation(s) and sometimes I don't get the latest builds or revisions of an app I was hoping for. I don't know if one is in the works or not is a simple script or a pre-compiled utility that will check the revisions and dates of the ports stuff of the station and automatically pull down any new versions. I know this might be helpful if you want to keep an older version, but the utility could have the option to keep older versions and rename the new ones.

Anywho... something I found quite nice in this month's issue was the article on Assembly. I might not be up to par on my C/C++, but learning a bit of Assembly would definitely be worth while for me.

Re:Assembly and Ports

[gsutter]

There is such a utility: CVSup. See the CVSup section [freebsd.org] of the FreeBSD Handbook [freebsd.org] for details.

You can also fetch and run CVSup very quickly and easily (as root) by issuing pkg_add -r cvsupit, which will go get the CVSupit package (a CVSup wrapped for easy installation and use), install it, and prompt you for what to do next.

Although these instructions are specific to FreeBSD, CVSup is an excellent tool for dealing with any source tree, including the other BSDs.

HTH!

Assembly quirks?

[howardjp]

Because Linux forces the user to pass system call arguments in the processor registers (and is it like this on all architectures?), does that mean it is limited in the number of arguments that can be passed?

Re:Assembly quirks?

[howardjp]

And, while I am at it, are arguments to library calls passed the same way under Linux?

Re:Assembly quirks?

[Odradek]

Nope. They go on the stack. (If they didn't, e.g. varargs functions like printf, sprintf, scanf, et al would not work.)

Re:Assembly quirks?

[Odradek]

Even memory verification aside, accessing something which is located in memory is slower than accesing a register. For instance:

mov eax, ebx

Is always faster than the single instruction:

mov eax, [ebx]

This is simply because registers are located in the processor and can be accessed in a single clock cycle, whereas even very fast cache RAM still takes a bit more than this, not to mention cache misses, et cetera.