Solved uint_t

lost_in_c

lost_in_c

So I'm done my first draft of my first .c that uses zfs functions. It's my first time doing something like this, so I'm trying it a way that is probably very hacky and anyway isn't working. Maybe somebody can point me in the right direction.

I simply cloned the zfs repository, #include'ed the relevant libraries, and then when I compiled I added -I $directory_with_the_zfs_repository. One of the files in that repository is zfs/zfs-master/include/os/freebsd/spl/sys/types.h, which includes typdefs for uint_t and several other ones that are needed (which I linked with #include <sys/types.h>). However, when I comile it with cc, I get:
Code: 
error: unknown type name 'uint_t'; did you mean 'uint8_t'?

What did I miss in my linking procedure?
 
go to /usr/src/cddl/sbin/zfs
look at Makefile
see what include dirs adds to the build

Makefile: 
        -I${ZFSTOP}/include \
        -I${ZFSTOP}/include/os/freebsd \
        -I${ZFSTOP}/lib/libspl/include \
        -I${ZFSTOP}/lib/libspl/include/os/freebsd \
        -I${SRCTOP}/sys \
        -I${SRCTOP}/cddl/compat/opensolaris/include \
        -I${ZFSTOP}/module/icp/include \
        -include ${ZFSTOP}/include/os/freebsd/spl/sys/ccompile.h \
        -DHAVE_ISSETUGID \
        -include ${SRCTOP}/sys/modules/zfs/zfs_config.h \
        -I${SRCTOP}/sys/modules/zfs
$ make -V ZFSTOP -V SRCTOP
/usr/src/sys/contrib/openzfs
/usr/src
 
So actually I had nothing in that directory. I don't know why or how that happened, but when I usd OpenZFS's guide to populate it, once I restarted the machine it wasn't able to mount zroot anymore. Thankfully this is a very fresh install with almost nothing on it, so I just reinstalled FreeBSD. It now is populated. Like other things, I think it may have to do with that I was deferring creating users hah. Who wants to run su every time, right? Anyway, lesson learned. Let's see how things work out now.

I did lose my .c, but it was actually a very small and very simple program. The days of work went into tracking down the exact functionality that I wanted and whittling it down to a point. Rewriting it will take minutes.

"Let's see," said a blind man.
 
So I did all that, and now I am back at the same error. Presumably, better armed to defeat it.

Now here's the quirky part: where the compiler is throwing the error is not my .c file itself, but /usr/include/sys/nvpair.h. It finds that, but mysteriously it doesn't find sys/types.h:
Code: 
In file included from krt.c:3
/usr/include/sys/nvpair.h:257:18 /*there are other lines on which it happens, just a random sample*/ error:unkown type name 'uint_t'; did you mean 'uint8_t?

I even added this line to the Makefile pointed to by covacat (second line shown):
Code: 
...
-I${ZFSTOP}/lib/libspl/include/os/freebsd\
-include ${SRCTOP}/sys/types.h\
-I${SRCTOP}/sys\
...
 
Huh. Well ain't that a thing. The types.h on my system doesn't have a typedef for uint_t, but the one in the git repository does.

Now why would such a thing be? Maybe I should build it form source? But then I'm scared my system will have trouble booting zroot again.
 
I've never seen a "uint_t" defined or used. Doesn't mean it "not exist" just I've not seen it. My understanding of all the "_t" was to specify types. uint8_t means "8 bit signed integer". uint_t what does that mean? "integer"? Well we get back to integer being 32 bits or 64 bits and circle to "what is uint_t"? 32 bit, 64 bit, 47bits?

The version in the git repo, what is the definition?
 
I thought it was weird too, but what do I know, all these guys have phds...

From /include/os/freebsd/spl/sys/types.h line 64:
Code: 
typedef u_int        uint_t;

Lol and opening up the file, I see this comment a little before:

Code: 
/*
 * This is a bag of dirty hacks to keep things compiling.
 */

In my case the file trying to make use of the type is /usr/include/sys/nvpair.h line 256 (but there are plenty other occurences).

Among others, I believe *wkeydata is just a plain uint_t.
 
Correctoin, that was wkeylen:

Code: 
lzc_create(const char *fsname, enum lzc_dataset_type type, nvlist_t *props,
    uint8_t *wkeydata, uint_t wkeylen)

From libzfs_core.c, line 302.
 
lost_in_c said:
I thought it was weird too, but what do I know, all these guys have phds...

From /include/os/freebsd/spl/sys/types.h line 64:
Code: 
typedef u_int        uint_t;

Lol and opening up the file, I see this comment a little before:

Code: 
/*
 * This is a bag of dirty hacks to keep things compiling.
 */

In my case the file trying to make use of the type is /usr/include/sys/nvpair.h line 256 (but there are plenty other occurences).

Among others, I believe *wkeydata is just a plain uint_t.
Click to expand...
Well, FreeBSD is Unix, and in the proper Unix tradition:
Code: 
*/ ... 
* You are not expected to understand this. 
*/ 
if(rp->p_flag&SSWAP) { 
                rp->p_flag =& ~SSWAP; 
                aretu(u.u_ssav); 
        }
Click to expand...

Just joking, sorry I can't help, but I'm watching this thread with great interest. Good luck 🤞
 
We'll keep going alreaught. Right now I'm just making peace with that I'm going to build from source, so I have to figure out how to get the .c out of the freebsd box.

If I have to, I will just paste needed files into the directory where my program is, and in future just manually replace them with each upgrade.
 
That's a fucking bingo.

Did all that, added -include /bla/bla/bla/zfs to the compiler, and it found the godrotting h file.

God bless the USA.
 
I browsed at this thread before all the other responses and started to respond but decided to wait until more folks chimed it.

the uint_t is NOT A STANDARD TYPE. It is most likely an alias/typedef that someone created to genericize the unsigned int for their particular platform, the processed being that the build would select the correct underlying type uint32_t, etc based on the target platform. ie "make configure"

Seems like the op is a bit out of their element with regard to "systems programming" so I'd suggest spending some liberal amount of time reviewing the ZFS source and build procedure before trying to expand on it or interface with it.
 
lost_in_c said:
That's a fucking bingo.

Did all that, added -include /bla/bla/bla/zfs to the compiler, and it found the godrotting h file.

God bless the USA.
Click to expand...

You'll probably want something like:

cc -I/usr/local/include -L/usr/local/lib/ -lname_of_the_lib_w/o_prefix-lib filename.c -o filename
 
kent_dorfman766 said:
I browsed at this thread before all the other responses and started to respond but decided to wait until more folks chimed it.

the uint_t is NOT A STANDARD TYPE. It is most likely an alias/typedef that someone created to genericize the unsigned int for their particular platform, the processed being that the build would select the correct underlying type uint32_t, etc based on the target platform. ie "make configure"

Seems like the op is a bit out of their element with regard to "systems programming" so I'd suggest spending some liberal amount of time reviewing the ZFS source and build procedure before trying to expand on it or interface with it.
Click to expand...
I don't have time to do it right, but thankfully I have time to do it twice. In the future, this is a free world of course, but specific advice will be more welcomed than "read a book." Thank you for your time and energy.
 
So here's the way I'm framing it now. And nobody should be under the impression that I am doing some extensive rewrite of the zfs repository, I am just scraping some functionality from it that I need which amounts to a few functions.

It strikes me that if I can get the exact same linking that zfs_main.c gets, then those two or three functions should work without a hitch. So what I am proposing to do now is get my own .c added to the build, just basically snuck in there right beside zfs_main.c.

while(you would do this for zfs_main.c){
do it also for randomfunctions.c
}
 
lost_in_c said:
I don't have time to do it right, but thankfully I have time to do it twice. In the future, this is a free world of course, but specific advice will be more welcomed than "read a book." Thank you for your time and energy.
Click to expand...
Sure nuff...and when the "short cuts" get into production commercial code guys like me get the pleasure of fixing it, but we are already suspect because the previous "long gone expert" took the "do it twice" instead of "do it right" approach. Sorry, but the lax attitude these days toward doing things right has become a huge pet peave of mine. I mean "its just software. How hard can it be?" LOL
 
Yes, thank you for your opinion, it is noted.

If one day you decide to become of use, that will be fine also.

I'm sure you have all sorts of frustrations in your life, so if you want to continue to use this thread for that, that's fine too. It's your time to waste.
 
Well, I don't know what just happened hahaha, but gmake install worked.

Will report back with results tomorrow. Or pictures of my smoldering FreeBSD machine.

Stay tuaned.
 
kent_dorfman766 said:
the uint_t is NOT A STANDARD TYPE. It is most likely an alias/typedef that someone created to genericize the unsigned int for their particular platform, the processed being that the build would select the correct underlying type uint32_t, etc based on the target platform. ie "make configure"
Click to expand...

Yeah.

1757251403847.png



^ From Dillo browser source code. In their case d_size.h is already in the source tree, but the way I see it this should've been autogen'ed. So this file looks like above for all possible build targets.

This is only shorthanding, typedefing to write less.

Perhaps they wanted to have flexibility in target-size configuration and autogen to emit the right header, but in the end it was satisfactory to just typedef to standard types.
 
What I was completely unprepared for was the maze of library dependencies for a project (zfs, not mine) of this scope and complexity. I sort of assumed too that at some point some level of the system sees uint_t as n empty placeholder for something else, and the utility was in having the placeholder for scripting rather than filling it in with something that will produce more hoops.

My approach, however, of just tracking down everything that gets generated for zfs_main and sneaking myownproject.c in right beside it worked. The whole uint_t problem is getting resolved by the scripts of much smarter people, and the compile errors I am now getting are the normal ones I would expect for a program like mine.

Of course, I now have to wait 2-3 minutes every time I want to check if it compiles, but maybe that will incentivize more careful coding on my part.

The adventure continues, but I guess I am marking this as solved.

Special thanks to covacat for aiming me in the right direction, kent_dorfman766 for some valuable clues, and vmisev for some others.
 
You must log in or register to reply here.
Back
Top