tce-load replacement potential

[CentralWare]

Hello all!

I am in the process of creating a replacement app (script) for tce-load due to the huge number of times I've found myself repo-digging and manually fetching extensions from one version (ie: 6.x) whilst running the current version (8.x) and though there's a chance a few of these extensions may break between versions, I cannot count how many times manually w'getting from the older repo has solved software issues in moments.

To accomplish this with the least amount of wasted time (reinventing the wheel type of research) I figure it easier and faster to simply ask.

1) Between x86/x64/RPi/etc. is there a common function/command/script which already exists to determine the architecture of the running machine?

2) Backward Compatibility: If I'm running Arm8 hardware (example), would it be safe to assume Arm6 extensions will, for the most part, operate on newer hardware?

3) Forward Thinking: Naming conventions change as the kernels and repo have discovered many times... an ongoing list of these changes would be recommended within the repo.  (A hardware based list which contains all of the kernel versions (4.x.x) and major release versions (8.x) supported by a given platform.)

4) I'm likely going to need some elaboration as to how OnDemand is intended to operate when adding items to it.  (Let's use "mc" as the example; when downloading, dependencies are assumed to be placed in $OPTIONAL, MC itself would presumably be placed in $ONDEMAND and the ondemand.lst file updated with mc.tcz???  Pure assumption here as I haven't studied the tc-* and tce-* files much.)

5) From an RPi standpoint, I was recently charting a project which is going to use a number of network based file systems and I'm curious as to whether or not items such as AoE and NFS are still supported?  (nfs-utils for example...  not listed since 5.x or 6.x repo?  VBlade I haven't looked for yet.  The question is based on both client and server perspectives.)

Thanks gents!

T.J.

[Misalf]

1)
/etc/init.d/tc-functions

Code: [Select]

getBuild() {
BUILD=`uname -m`
case ${BUILD} in
armv6l) echo "armv6" ;;
armv7l) echo "armv7" ;;
i686)   echo "x86" ;;
x86_64) [ -f /lib/ld-linux-x86-64.so.2 ] && echo "x86_64" || echo "x86" ;;
*)      echo "x86" ;;
esac
}


[CentralWare]

@Misalf: Thank you for the pointer to getBuild().  This should help with calling which kernel/version of TCL is installed, which is the goal for today, but I imagine I'll eventually need actual hardware determined specs for this project to completely show its true potential.  (eg. Anyone can install TCLx86 on an x64 or TCLArm6 on an actual Arm7, but uname is only going to respond based on what it was told when it was compiled, not what hardware is actually within.  Due to TC's modular structure, up/downgrading the running version of the operating system in many cases would be tremendously simplistic if only there was a sure-fire means to gather physical architecture. /proc/cpuinfo may be worthwhile, but I can imagine x86/x64 processors would likely have a great deal of variances where a running database would end up being required if such a thing doesn't already exist.)

[curaga]

No, uname gets its information from /proc or the kernel, it's not hardcoded at build time. (Well, if from the kernel, it's hardcoded at the kernel's build time of course)

edit: The flag in cpuinfo that tells if a x86 processor is 64-bit is "lm" (long mode).

[CentralWare]

@curaga: lol...  yes, at the kernel's build time
Thank you for the x64 processor flag (God forbid we ever see/hear about an 80x86/128bit )
Thank God I don't have to get a list of all of the processor flags for the past 35 years!!

And to think...
The first IBM PCs (and eventually their "Compatibles") were built around an 8088, or "XT" processor.  Eight whopping bits and a handful of memory running at a few MHz if you were lucky.  Hard drive?  Universal Serial What?  LOL...  this heavy-weight (steel enclosure) computer like the IBM 5150 came to exist about the same time the Audio CD was invented...  can't say for sure which was more powerful at the time!

The next generation was the 8086 processor with its overwhelming...  oh wait... it's just a faster XT.

The 80286 processor was the true paving of the future (and most all flaws that existed with this architecture have been replicated for thirty years now! )  Sixteen bits which opened the door to more memory addressing, a dual IRQ chip and more times than not, the need for an RTC. Anyone still have some old ISA expansion cards...  for nostalgia, maybe?

Adventure and technical improvements have climbed the 80#86 ladder over the years, but one would think we'd be in the double-digits by now considering it's been years (early 1980s) since the 286/287's were common-place.

[Rich]

Hi centralware

And to think...
The first IBM PCs (and eventually their "Compatibles") were built around an 8088, or "XT" processor.  Eight whopping bits and a handful of memory running at a few MHz if you were lucky.

Actually the 8088 is a 16 bit processor with a 20 bit address bus capable of addressing 1 megabyte of memory. The external
data bus is 8 bits wide.

The next generation was the 8086 processor with its overwhelming...  oh wait... it's just a faster XT.

Intel put out the 8086 before the 8088. The primary differences being the 8086 external data bus is 16 bits wide and the depth
of the prefetch queue is 6 bytes instead instead of 4 bytes.

The 80286 processor was the true paving of the future (and most all flaws that existed with this architecture have been replicated for thirty years now!  )  Sixteen bits which opened the door to more memory addressing,

The 80286 has a 24 bit address bus allowing it to address 16 megabytes of memory when running in protected mode. When
running in real mode it basically behaved just like an 8086.